Browser history leakage
11Codes and tokens in visited URLs can remain in history, where someone with device access may find them.
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
DIAGRAM§ 4.3 ↗
RFC 9700 · § 4.3DEFENSE
3 / 3
03
Never navigate with access_token in the query.
Resource access should not distribute tokens through visited addresses.
Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
Read the updated RFC section ↗
Never put access tokens in URI queries.
- Clients MUST NOT pass access tokens in URI query parameters.
- Code replay prevention and transaction binding reduce the value of a code found in history.
- Authorization code and form post responses can reduce front-channel credential exposure.
The implicit grant can also leave tokens in URL fragments in browser history. The drawing represents local history access; it does not imply any website can read the browser’s full history.
Read the RFC section ↗Diagrams simplify the RFC. Read the linked sections for complete requirements.
PrivacyAll chapters in this RFC
- OAuth overview
- Authorization code + PKCE
- Retire unsafe grants
- Prevent token replay
- Limit token privileges
- Authenticate the client
- Metadata, TLS & CORS
- The attacker model
- Redirect URI validation
- Referer header leakage
- Browser history leakage
- Authorization server mix-up
- Authorization code injection
- Access token injection
- Cross-site request forgery
- PKCE downgrade
- Leakage at resource servers
- Misuse of stolen tokens
- Open redirection
- 307 credential forwarding
- TLS termination & proxies
- Refresh token protection
- Client as resource owner
- Clickjacking
- In-browser messaging