Client-side tracking can be blocked, altered, or exposed to third-party script risk, which makes the data incomplete and less trustworthy. It can also slow the page and create governance concerns around sensitive authentication information. Server-side event delivery is more reliable for measuring the funnel and reduces the chance that analytics code interferes with the authentication experience.
Why This Matters for Security Teams
Tracking authentication only in the browser turns a security signal into a fragile telemetry source. Client-side code can be blocked by extensions, altered by injected scripts, dropped on page failures, or exposed when third-party scripts share the same execution context. That makes funnel metrics incomplete and weakens auditability around login, MFA, session creation, and recovery events. It also introduces governance risk because authentication data often touches sensitive identity state.
Security teams should treat the browser as an untrusted reporting layer, not the source of record. Guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls and ISO/IEC 27001:2022 Information Security Management both point toward trustworthy logging, controlled collection, and integrity of security records. NHIMG research shows why browser-side exposure is not theoretical: secrets and identity artifacts routinely leak through tooling and third-party ecosystems, including Code Formatting Tools Credential Leaks and Hard-Coded Secrets in VSCode Extensions.
In practice, many security teams discover missing authentication events only after fraud, login abuse, or incident reconstruction has already exposed the gap.
How It Works in Practice
Reliable authentication telemetry should originate from the server, identity provider, or auth service, then be enriched with client context rather than generated only in the browser. That means emitting events at decisive points such as credential submission, MFA challenge, token issuance, session refresh, and logout, then correlating them with request identifiers, user agent data, and risk signals. The browser can still provide useful context, but it should not be the only record of what happened.
This approach improves integrity because the backend controls the authoritative event stream. It also supports stronger detection logic: repeated failures, impossible travel, abnormal device changes, or MFA fatigue can be evaluated against a more complete record. NIST logging guidance and common security telemetry practice favor controlled, tamper-resistant event sources, while NHIMG has documented how identity-related exposure expands when sensitive actions are left to weak collection paths, including the patterns described in JetBrains GitHub plugin token exposure.
- Log authentication milestones on the server, not just in JavaScript.
- Use correlation IDs so frontend and backend events can be matched safely.
- Send only the minimum necessary client context to avoid over-collection.
- Protect event integrity with access controls, retention rules, and immutable storage where warranted.
- Validate that analytics or tag managers cannot suppress or duplicate security events.
These controls tend to break down in single-page apps with third-party tag managers and heavy client-side routing because event timing becomes inconsistent and the browser cannot guarantee delivery.
Common Variations and Edge Cases
Tighter server-side collection often increases engineering overhead, requiring organisations to balance telemetry completeness against deployment complexity. That tradeoff becomes more visible in privacy-sensitive environments, distributed front ends, and systems that rely on external identity providers.
There is no universal standard for every browser instrumentation pattern yet, but current guidance suggests treating client-side events as auxiliary evidence, not the source of truth. For example, a front end may record UI intent such as button clicks or error messages, while the backend records the actual authentication outcome. That separation reduces the risk of false success events caused by script errors or malicious manipulation. It also helps when security teams need to reconstruct a session without relying on data that a user can disable, modify, or intercept.
Edge cases include offline-first applications, embedded web views, and federated login journeys where the browser temporarily leaves the primary domain. In those cases, design for eventual reconciliation instead of assuming the client can reliably report every step. NHIMG’s research on the Ultimate Guide to NHIs shows how incomplete visibility becomes a systemic risk, especially when identity controls are already fragmented. The same logic applies here: if the event path can be altered by the client, it is not a dependable security record.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Auth events need trustworthy identity telemetry, not browser-only reporting. |
| OWASP Agentic AI Top 10 | A-04 | Untrusted client telemetry mirrors the need for runtime trust decisions in dynamic systems. |
| CSA MAESTRO | TRA-03 | MAESTRO emphasizes trustworthy telemetry and control-plane visibility for autonomous systems. |
| NIST CSF 2.0 | DE.CM-1 | Security monitoring depends on complete, trustworthy event sources. |
| NIST SP 800-53 Rev 5 | AU-2 | Audit event generation must capture security-relevant authentication actions. |
Record authentication activity at authoritative backend points and treat client telemetry as supplemental only.
