Learn the vocabulary of defending against a page embedded in an invisible attacker iframe.
0 / 5 completed
1 / 5
At standup, a dev mentions an attacker embedding the company's site in an invisible iframe layered under a decoy button, tricking a user into clicking something they never actually saw. What is this attack called?
Clickjacking embeds the company's site in an invisible iframe layered under a decoy button on the attacker's own page, tricking a user into clicking something on the real site they never actually saw or intended to interact with. Cross-site scripting instead injects a malicious script into a page, which is a different attack vector entirely. This invisible-iframe trickery is what makes clickjacking dangerous even against a site that otherwise has no injection vulnerability at all.
2 / 5
During a design review, the team wants a response header that tells the browser exactly which origins, if any, are allowed to embed a page in an iframe. Which capability supports this?
A Content-Security-Policy frame-ancestors directive, or the older X-Frame-Options header, tells the browser exactly which origins, if any, are allowed to embed the page in an iframe, and the browser refuses to render the page inside a frame from any other origin. Serving the page with no such restriction leaves it embeddable by any attacker's page, which is precisely what a clickjacking attack depends on. This header-based restriction is the standard, browser-enforced defense against clickjacking.
3 / 5
In a code review, a dev notices a legacy page relies solely on a client-side JavaScript 'framebusting' script to detect and break out of an iframe, with no server-side header restricting embedding at all. What does this represent?
This is a weaker, bypassable clickjacking defense compared to a server-enforced header, since a client-side framebusting script can often be neutralized by the very attacker page hosting the iframe, for instance by suppressing the script's ability to navigate the top frame. A CORS preflight request is an unrelated concept about cross-origin request headers, not iframe embedding. This is why a server-enforced frame-ancestors or X-Frame-Options header is considered the more robust defense, since the browser itself refuses to render the frame rather than depending on a script the attacker's page can potentially interfere with.
4 / 5
An incident report shows users were tricked into unknowingly authorizing a fund transfer through an invisible iframe overlay on an attacker's page, because the banking site's pages had no frame-ancestors restriction or X-Frame-Options header set at all. What practice would prevent this?
Setting a Content-Security-Policy frame-ancestors directive, or the older X-Frame-Options header, restricts embedding to trusted origins only, so the browser refuses to render the sensitive page inside the attacker's invisible iframe in the first place. Continuing to serve the pages with no such restriction is exactly what allowed the invisible-overlay attack that tricked users into authorizing a transfer in this incident. This header-based restriction is a mandatory defense for any page that performs a sensitive, state-changing action a user could be tricked into triggering.
5 / 5
During a PR review, a teammate asks why the team sets a server-enforced frame-ancestors directive instead of relying on a client-side JavaScript framebusting script to prevent the page from being embedded in an iframe. What is the reasoning?
A client-side framebusting script can often be neutralized by the very attacker page hosting the iframe, since that attacker page controls enough of the surrounding environment to interfere with the script's ability to detect or break out of the frame. A server-enforced header is instead honored directly by the browser itself, independent of anything the embedding page's own script tries to do. The tradeoff is essentially none here, since the server-enforced header is strictly more reliable, which is why it's the recommended primary defense rather than a script-based workaround.