Identity material stored where JavaScript can access it, such as cookies without HttpOnly or local storage. When that material can be read by scripts, extensions, or agent code, it becomes a bridge from temporary session access to persistent credential creation.
Expanded Definition
Browser-readable identity state is any authentication material a browser can expose to script execution, browser extensions, or agent code. That includes tokens in local storage, non-HttpOnly cookies, and other client-side state that can be repurposed to impersonate a user or workload. In NHI security, the distinction is not simply “stored in a browser” but “readable by code running in the browser context,” because read access creates a path from transient session use to durable credential theft.
Definitions vary across vendors when browser state is treated as a convenience layer for single sign-on, but no single standard governs this yet. The practical security boundary is whether the identity material is protected from script access and replay. NHI Management Group treats this as a high-risk exposure because browser-readable state is often the easiest place for secrets to leak during hybrid human-and-agent workflows, especially when agents inherit browser context. Guidance from NIST Cybersecurity Framework 2.0 aligns with this concern by emphasizing access control and data protection outcomes.
The most common misapplication is assuming that a session token is safe because it is “temporary,” which occurs when developers store it in a browser location readable by JavaScript.
Examples and Use Cases
Implementing browser session handling rigorously often introduces friction, requiring teams to weigh easier frontend integration against a reduced attack surface for token theft and replay.
- A single-page application stores an access token in local storage for convenience, but any injected script can read it and mint API calls as the user.
- A service dashboard uses a cookie without HttpOnly, allowing malicious browser extensions or compromised scripts to exfiltrate the session and impersonate an operator.
- An AI agent acts inside a browser session and inherits readable state, turning a limited browsing task into persistent access to downstream tools and APIs.
- A third-party support widget runs in the page context and can observe identity material that should have been isolated from JavaScript.
- In breach analysis, NHIMG has shown how exposed tokens in browser-adjacent contexts amplify supply-chain risk, including cases discussed in 52 NHI Breaches Analysis and JetBrains GitHub plugin token exposure.
These patterns are best understood alongside modern identity guidance such as the NIST Cybersecurity Framework 2.0, which supports reducing exposure through stronger control design and monitoring.
Why It Matters in NHI Security
Browser-readable identity state is dangerous because it collapses the boundary between authenticated use and credential extraction. Once a token or session artifact is readable by script, an attacker does not need to break cryptography or bypass central IAM controls. They only need one injection point, one malicious extension, or one compromised agent context. That is especially relevant for NHIs, where browser sessions may be used to bootstrap API access, automate admin tasks, or hand off identity state between tools.
NHI Management Group reports that Ultimate Guide to NHIs identifies how widespread insecure secret storage is, including 96% of organisations storing secrets outside of secrets managers in vulnerable locations and 79% experiencing secrets leaks. Those conditions make browser-readable state a recurring source of persistent compromise rather than a minor implementation flaw. The issue also intersects with supply-chain exposure described in Code Formatting Tools Credential Leaks, where browser or extension access can become an identity exfiltration path.
Organisations typically encounter the consequences only after an account takeover, extension compromise, or agent-driven data exfiltration, at which point browser-readable identity state becomes operationally unavoidable to address.
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 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Browser-readable identity state is a secret exposure and storage risk under NHI controls. |
| NIST CSF 2.0 | PR.AC | The term maps to access control and credential exposure outcomes in the CSF. |
| NIST Zero Trust (SP 800-207) | SC-2 | Zero Trust requires minimizing trust in client-side state that can be read or replayed. |
| NIST SP 800-63 | AAL2 | Session material that can be read by scripts weakens authenticator assurance expectations. |
| OWASP Agentic AI Top 10 | Agent code in a browser context can exfiltrate readable identity state. |
Use stronger session protections and avoid storing authenticators in script-readable browser locations.
