Clickjacking
24A hidden frame or deceptive overlay can turn an innocent click into consent, or capture a password intended for the real login page.
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
DIAGRAM§ 4.16 ↗
RFC 9700 · § 4.16DEFENSE
3 / 3
03
Let the user make an informed decision.
Protect all relevant authentication and authorization screens.
Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
Read the updated RFC section ↗
Protect the entire authorization interface.
- Authorization servers MUST prevent clickjacking.
- Servers SHOULD use CSP level 2 or greater, including frame-ancestors and appropriate script restrictions.
- Apply controls across authorization, login, device authorization, and error pages as applicable. Combine defenses for legacy agents unless they are explicitly unsupported.
Frame policy must fit legitimate embedding requirements. The RFC recommends configurable permitted origins per client; relying on one protected page leaves other authorization screens exposed.
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