What are the best practices for clickjacking defence?

How clickjacking defence works in practice

Clickjacking defence is about controlling whether your pages can be embedded in another site and then ensuring that important UI actions still require an intentional, trusted user interaction. The core idea is simple: if an attacker cannot frame the page, they cannot easily layer deceptive controls over your buttons, forms, or consent prompts. When framing is legitimate, the risk shifts to narrowing which pages may be embedded and which actions still need extra confirmation.

A practical defence starts with the browser’s framing controls, then moves to workflow design. Pages that handle sign-in, account changes, payment approval, or consent should not rely on visual placement alone to prove intent. If a page must be embeddable for a business reason, the application should still treat high-impact actions as trust boundaries and require stronger confirmation before they execute.

For teams standardising this pattern, the Security Headers Guide is a useful reference point because it ties framing controls to the wider set of HTTP protections that tend to be deployed together. That matters in practice, since clickjacking is often addressed alongside content security policy, cookie hardening, and related response-header configuration rather than as a standalone tweak.

Which pages need the strongest clickjacking protection?

Not every page carries the same exposure. The highest priority is any workflow where a misclick can cause a material security, financial, or consent outcome, especially account management, payment flows, admin functions, and permission grants. Public informational pages are lower risk, but any page that contains a destructive, privacy-impacting, or state-changing control deserves more scrutiny.

The best rule is to classify pages by consequence, not by appearance. If a page can change credentials, transfer value, approve access, or authorise something the user did not clearly intend, treat it as high risk. Those pages may need stricter frame blocking, stronger confirmation, or a complete redesign so the sensitive action cannot be executed through a deceptive overlay.

For defence-in-depth thinking, CIS Controls v8 remains relevant because clickjacking is not only a front-end problem. It intersects with secure configuration, access control, and auditability, so the same page should be reviewed as part of a broader control set rather than as a one-off browser setting.

When framing is allowed, what should still be protected?

Some organisations allow framing for limited reasons, such as partner portals, support widgets, or embedded product experiences. In those cases, the defence should become more selective: allow only the minimum set of pages that truly need embedding, and keep sensitive operations out of framed contexts where possible. The more a page changes state or reveals protected information, the less suitable it is for embedding.

Even when a page is allowed to frame, sensitive actions should be guarded with explicit user confirmation and, where appropriate, re-authentication. That extra step is valuable because it forces a deliberate decision at the point of impact rather than trusting a single click inside a potentially deceptive visual context. It is especially important for consent, deletion, payment, and privilege-related flows.

Where you need a broader control model for the page and its surrounding trust boundary, NIST SP 800-53 Rev 5 Security and Privacy Controls provides a useful anchor for thinking about access control, configuration control, and monitoring as part of the same protection strategy.

Risk and Threat Considerations

Clickjacking risk is highest when a user believes they are interacting with a trusted page but is actually clicking on an attacker-controlled overlay. The failure is not only visual deception, it is trust abuse, because the browser will still deliver the user’s action to the framed application if the page is allowed to load that way.

Failure mechanism: The application permits framing, or applies framing controls inconsistently, and a sensitive control can be positioned under an attacker’s visible interface. The user’s click lands on the protected page without realising it, which can trigger an action that would never have been chosen intentionally.

Impact: Attackers can coerce account changes, consent grants, payment authorisations, or other state-changing actions with minimal friction. In the worst case, the attack turns a single click into unauthorised access, unwanted transactions, or a trust decision the user did not mean to make.

Practitioner Guidance

What to verify: Confirm that every sensitive page has an intentional framing decision, not an accidental default. For each page that can change state, verify both the header or policy behaviour and the business requirement for embedding, because the technical control is only correct if the product decision is correct too.

Decision rule: If a page can change credentials, money, permissions, or consent, treat frame blocking as the default and require a documented exception before allowing embedding. If embedding is unavoidable, move the highest-risk action behind a separate confirmation step that cannot be satisfied by a casual click.

Common mistake: Teams often protect the login page and then leave the post-login account settings, billing, or consent pages exposed. That is where clickjacking becomes more damaging, because the attacker no longer needs to steal a password, only manipulate a trusted session into doing something harmful.

Practitioner takeaway: The control is strongest when you combine browser-level frame restrictions with workflow-level friction on high-impact actions, because clickjacking is ultimately a trust problem, not just a header problem.

Related resources from NHI Mgmt Group

• Why do defence in depth and best practices still leave organizations exposed to attack paths?
• How should security teams make NHI best practices usable across the business?
• Why do architecture best practices matter so much for access systems?
• How should cloud teams enforce AWS Foundational Security Best Practices across Infrastructure as Code?