What breaks when refresh tokens can be read from cross-site browser requests?

Why This Matters for Security Teams

When refresh tokens can be read from cross-site browser requests, the browser stops being a safe session boundary and becomes a credential bridge. That matters because refresh tokens are not just another cookie value. They are the mechanism that can mint new access on demand, which means exposure can persist long after the original request has finished. The risk is especially high in apps that allow workflow editing, integrations, or embedded secrets handling.

This pattern is not theoretical. NHIMG research on the Salesloft OAuth token breach and the Guide to the Secret Sprawl Challenge shows how token exposure often turns into downstream access to business systems rather than staying contained at the browser layer. For control design, NIST SP 800-53 Rev 5 Security and Privacy Controls remains the cleanest baseline for session, access, and token handling requirements.

In practice, many security teams encounter abuse only after a cross-site flow has already been used to silently refresh a session and reach sensitive application paths.

How It Works in Practice

The failure starts when a refresh token is accessible in a browser context that can be triggered cross-site. If an attacker can cause the browser to send or reveal that token, the attacker can often obtain a fresh access token without needing the user’s password or the original page interaction. That breaks the intended separation between a front-end request and a privileged session renewal.

For browser-based applications, the right model is usually to keep refresh tokens out of script-accessible and cross-site reachable contexts. Best practice is evolving, but current guidance generally favors short-lived access tokens, stricter cookie scoping, and anti-CSRF protections so that a cross-site request cannot become an authentication event. Where sessions must persist, many teams also use token rotation and server-side detection of reuse so that a stolen refresh token has a narrow lifetime.

In operational terms, the important questions are:

• Can the refresh token be sent automatically by the browser on a cross-site request?
• Can any JavaScript on the page read it or trigger a renewal flow?
• Does refresh-token reuse cause revocation, or can the token be replayed repeatedly?
• Does the application bind refresh behavior to the expected site, origin, or user action?

This is where browser security, session management, and NHI governance meet. The 2025 State of NHIs and Secrets in Cybersecurity reports that 44% of NHI tokens are exposed in the wild, which reinforces a simple operational truth: once a token can be copied or replayed, its location matters less than its revocation path. For implementation details, the NIST control catalog is useful for mapping token protection, session invalidation, and access enforcement requirements. These controls tend to break down in single-page apps that rely on long-lived browser storage and third-party embedding because cross-origin execution paths become hard to predict and harder to contain.

Common Variations and Edge Cases

Tighter token handling often increases implementation overhead, requiring organisations to balance user experience against stronger session containment. That tradeoff becomes sharp in apps that use embedded widgets, federated sign-in, or legacy single-page architectures.

One common edge case is a browser app that needs background session renewal but also loads third-party content. Another is an app that stores refresh tokens in cookies but does not fully enforce origin checks, making cross-site request handling the weak point. There is no universal standard for this yet, but current guidance suggests treating refresh capability as a high-value privilege, not a convenience feature.

This is also where lifecycle failures matter. If a stolen refresh token can keep generating new access tokens after logout, password change, or role change, the session revocation model is incomplete. NHIMG’s Guide to the Secret Sprawl Challenge is a useful reminder that exposure often spreads across systems faster than teams expect. For browser-facing systems that also touch sensitive business workflows, the safest posture is to make refresh tokens harder to read, harder to replay, and easier to revoke than the rest of the session state.

Related resources from NHI Mgmt Group

• What breaks when a dependency uses build scripts to read private source trees?
• What challenges do browser extensions pose to enterprise security?
• What actions should I take if my OAuth tokens are compromised?
• How do attackers operationalise stolen OAuth tokens at scale?