Clickjacking is a quiet attack because it uses your real app against your real user. The attacker embeds your page in a transparent frame on their own site, positions a decoy under it, and the user's click passes through to your app, which happily acts on it because the user is logged in. Nothing about your app looks wrong; the trick is entirely on the attacker's page.
How it works
The attacker loads your page in an iframe made invisible and placed over a decoy, so a click meant for the decoy lands on a control in your framed app, for example a confirm or delete button, run with the victim's own session. The concept in full is in what clickjacking is.
Want to see exactly what Prbl flags? Watch it scan a demo app, no repo or account needed.
See a live scan →The fix: refuse to be framed
Send headers that tell browsers your site may not be embedded by other origins:
// modern control (in your response headers or framework config) Content-Security-Policy: frame-ancestors 'self'; // legacy backstop for older browsers X-Frame-Options: SAMEORIGIN
With framing denied, the invisible-overlay trick cannot load your page, so the whole attack falls apart. Use frame-ancestors 'none' if your app never frames its own pages. The full walkthrough is in the fix for clickjacking protection, and it is one of several security headers AI-built apps tend to omit.
Frequently asked questions
What is clickjacking?
It is an attack that loads your site inside an invisible or disguised frame on a malicious page, positioned so the user's clicks land on your app instead of what they think they are clicking. The victim believes they are interacting with the attacker's page, but their clicks pass through to your site, using their own logged-in session.
What can an attacker accomplish with it?
Anything a click can do while the user is logged in. If a single click confirms an action, changes a setting, deletes something, or approves a request, an attacker can frame that control and trick the user into clicking it without realizing. It turns a legitimate one-click action into one the user performs unknowingly on the attacker's behalf.
Why do AI-built apps ship without protection?
Because the app works identically whether or not it can be framed. Nothing in normal use or testing requires the anti-framing header, so it simply never gets added. The gap only matters when someone deliberately embeds your page, which does not happen during development, so the missing header goes unnoticed.
How do I stop it?
Tell browsers not to let your site be framed by others. Send a Content-Security-Policy with frame-ancestors set to your own origin, or 'none' if you never frame your own pages, which is the modern control. Add the older X-Frame-Options header for legacy browsers. With framing denied, the invisible-overlay trick cannot load your page at all.
Check your headers
A missing anti-framing header is easy to overlook because the app works fine without it. A scan flags the gap so you can add the header before someone frames a sensitive action. Run a free scan and see whether your app can be framed.