Cross-site request forgery
15An attacker sends an unsolicited callback to a victim’s browser, causing the client to connect to resources chosen by the attacker.
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
DIAGRAM§ 4.7 ↗
RFC 9700 · § 4.7DEFENSE
3 / 3
03
Accept only the expected response.
Validate the binding and consume one-time values.
Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
Read the updated RFC section ↗
Bind the response to the initiating browser.
- Clients MUST prevent CSRF. Use a one-time, session-bound state token unless PKCE or OIDC nonce provides the protection.
- Before relying on PKCE for CSRF, clients MUST ensure server support. Without that support, use state or nonce.
- If application state integrity matters, protect state from tampering and swapping.
PKCE protects against CSRF even with an attacker who reads authorization responses. Leaked state can be replayed; nonce exposed in a front-channel ID Token has related limits.
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