Clickjacking (UI Redress)
detect, understand, remediate
Clickjacking tricks users into clicking hidden UI elements by overlaying a transparent iframe on a malicious page, enabling unauthorized actions like changing account settings or initiating transfers.
No credit card required. Free plan available forever.
What is clickjacking?
Clickjacking, also known as UI redress attack (CWE-1021), is a technique where an attacker tricks a user into clicking on something different from what they perceive. The attacker loads the target application inside a transparent or disguised iframe on a malicious page, then overlays deceptive content that entices the user to interact. When the user clicks what they believe is a button on the attacker's page, they are actually clicking on a hidden element in the embedded target application.
This vulnerability enables attackers to perform actions on behalf of authenticated users without their knowledge. Common exploitation scenarios include changing account settings, transferring funds, enabling microphone or camera access, liking or sharing social media content, and even executing administrative actions. Because the victim's browser sends valid session cookies with each click, the target application processes the action as a legitimate authenticated request.
Clickjacking is fundamentally a missing security headers issue. Applications that do not set X-Frame-Options or Content-Security-Policy frame-ancestors directives leave themselves open to being embedded by any malicious site. Combined with cross-site scripting or social engineering, clickjacking can be part of a multi-stage attack chain that achieves significant impact.
How it works
Create malicious page
The attacker builds a web page with enticing content (fake buttons, games, prize claims) designed to attract victims and encourage interaction.
Embed target in iframe
The target application is loaded in a transparent iframe positioned over the attacker's page, aligned so that critical buttons or links overlap the decoy content.
Overlay invisible elements
CSS opacity, z-index, and positioning are used to make the iframe invisible while keeping it interactive. The victim sees only the attacker's decoy content underneath.
User clicks hidden UI
When the victim clicks on the visible decoy, their click passes through to the invisible iframe, triggering the real action (changing settings, confirming transfers, granting permissions) on the target site.
Common causes
Missing X-Frame-Options header
The server does not send the X-Frame-Options response header (DENY or SAMEORIGIN), allowing any external site to embed the application in an iframe without restriction.
Missing CSP frame-ancestors directive
The Content-Security-Policy header does not include a frame-ancestors directive, or it is set too permissively, failing to restrict which origins can embed the page.
No JavaScript framebusting protection
The application lacks client-side framebusting scripts that detect when the page is loaded inside a frame and break out of it or refuse to render content.
Third-party widget embedding requirements
Applications that need to be embedded by partner sites often relax framing restrictions broadly instead of limiting allowed origins, creating exploitable gaps.
How to detect it
Automated detection
- SecPortal's external scanner checks all response headers for missing or misconfigured X-Frame-Options and CSP frame-ancestors directives
- Security header analysis flags pages that can be embedded in iframes, highlighting which sensitive actions (login, settings, payments) are exposed to clickjacking
- Iframe embed testing automatically loads discovered pages inside frames to verify whether framing protections are effectively enforced by the browser
Manual testing
- Create a simple HTML page with an iframe pointing to the target application and verify whether it loads successfully in the frame
- Inspect HTTP response headers in browser developer tools to verify X-Frame-Options and Content-Security-Policy directives are present and correctly configured
- Test specific sensitive pages (login, account settings, payment forms, admin panels) individually, as framing protections may be inconsistently applied across the application
How to fix it
Set X-Frame-Options to DENY or SAMEORIGIN
Add the X-Frame-Options response header to all pages. Use DENY to prevent all framing, or SAMEORIGIN to allow framing only from the same origin. Apply this header consistently across every response.
Deploy CSP frame-ancestors directive
Set Content-Security-Policy: frame-ancestors 'none' (equivalent to DENY) or frame-ancestors 'self' (equivalent to SAMEORIGIN). CSP frame-ancestors supersedes X-Frame-Options and supports specifying allowed origins.
Implement JavaScript framebusting as defense-in-depth
Add client-side code that detects when the page is loaded in a frame and either breaks out (top.location = self.location) or hides content. This provides protection for older browsers that may not support CSP.
Use SameSite cookie attribute
Set the SameSite attribute on session cookies to Strict or Lax. This prevents the browser from sending cookies in cross-site iframe requests, neutralizing clickjacking attacks even if framing is possible.
Require user interaction confirmation for sensitive actions
Implement confirmation dialogs, CAPTCHAs, or re-authentication for critical actions like account changes, fund transfers, and permission grants. These additional steps cannot be silently triggered through a single click.
Compliance impact
Check your clickjacking protection
SecPortal verifies X-Frame-Options and CSP frame-ancestors headers in every external scan. Start free.
No credit card required. Free plan available forever.