Referer header leakage
10External resources or links on OAuth pages can disclose sensitive URL contents through the Referer header.
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
DIAGRAM§ 4.2 ↗
RFC 9700 · § 4.2DEFENSE
3 / 3
03
Consume codes and state only once.
Replay checks reduce reuse after the legitimate transaction completes.
Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
Read the updated RFC section ↗
Keep OAuth pages free of leakage paths.
- Authorization and callback pages SHOULD NOT include third-party resources or external links.
- An appropriate Referrer-Policy, such as no-referrer, suppresses referrer disclosure.
- Bind codes with PKCE or confidential-client credentials; invalidate codes after use and SHOULD invalidate state after its first use. Form post is another option.
The authorization page can leak state before it is consumed. A callback can leak codes. Single-use codes help after redemption, but a thief can race the legitimate client; duplicate redemption SHOULD trigger revocation of previously issued tokens.
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