What are common mistakes with clickjacking defence?

Where clickjacking defence usually goes wrong

clickjacking defence fails most often when teams treat it as a single-header task instead of a page-by-page control. The main error is assuming one mechanism is enough everywhere, when real coverage depends on how the application embeds content, which browsers users actually run, and whether the protected page is one that can trigger meaningful action or disclose sensitive state.

A second common mistake is choosing a defence that only looks good in testing. Front-end overlays, JavaScript frame-busting, or inconsistent header deployment can appear to work while still leaving some routes embeddable, especially if legacy pages, error pages, or alternate hostnames are missed. The protection has to be enforced by the browser, not by the page’s own script.

Security Headers Guide is the most relevant reference when you want to see clickjacking defence in the wider context of framing, CSP, and rollout discipline across an application.

Why partial protection creates a real exposure

Partial coverage is risky because clickjacking only needs one exposed page to become useful to an attacker. If a login, consent, transaction, settings, or data-view page can still be framed, the attacker may be able to induce actions the user did not intend or hide the real destination behind a convincing overlay. Defence should therefore be judged by the most sensitive reachable page, not by the page that was easiest to configure.

Inconsistent controls also create false confidence during change. Teams sometimes protect only the main application shell while leaving admin paths, old routes, or partner-facing pages unprotected. That gap matters because the attack surface is often uneven, and browsers apply framing rules to each response independently. A defence strategy that does not verify every relevant route is a route-by-route exception list in practice.

CIS Controls v8 is useful here because clickjacking failures often sit alongside broader configuration and access-control weaknesses that need consistent implementation rather than isolated fixes.

NIST Cybersecurity Framework 2.0 also helps frame the issue as a governance and assurance problem, not just a header-setting exercise.

How to verify the defence is actually present

Verification should focus on the exact pages and user journeys that matter, not only on the presence of a preferred header. Check the final browser response for the routes that perform actions, reveal account data, or change security settings, and confirm the protection is applied to redirects, error handling, and alternate entry points as well. If the defence is implemented through policy headers, confirm the browser is receiving the policy you expect on the live page.

Testing should also include browser behaviour, because security controls can behave differently across user agents, embedded contexts, and old application paths. A control that passes in one browser or on one page template is not a complete result. The practical question is whether the browser will refuse the embedding attempt on the exact page that matters.

CISA Known Exploited Vulnerabilities Catalog is not a clickjacking reference itself, but it is a useful reminder to verify controls against real exploitation conditions, not only against expected configuration.

Practitioner Guidance

What to prioritise: Protect the pages that can change state, expose account data, or trigger high-value actions first. Those pages determine whether the defence is materially effective, because clickjacking impact comes from what the framed page can do, not from the elegance of the control setting.

What to verify: Confirm that the same protection is present on every route users can actually reach, including older paths, alternate hostnames, and error states. The common failure is not absence of a defence everywhere, but uneven deployment across the parts of the application that teams forget to test.

Common mistake: Do not treat JavaScript frame-busting or one-off UI tricks as equivalent to a browser-enforced framing policy. Those techniques are brittle, can be bypassed, and often fail exactly where a real attacker benefits most.

Practitioner takeaway: Clickjacking defence is only reliable when it is uniform, browser-enforced, and validated on the specific pages that matter most to the business.

Related resources from NHI Mgmt Group

• What are common mistakes with delimiter defence?
• What are the most common mistakes organisations make when launching green banking or telecom initiatives?
• What are the most common mistakes organizations make in a NIST SP 800-171 self-assessment?
• What are the most common mistakes teams make when implementing two-factor authentication for accounts?