Clickjacking

A visual deception technique that tricks a person into clicking a control they did not intend to use. In identity workflows, it can cause an autofill or approval action to happen in the wrong page context, even when the underlying secret store remains protected.

Expanded Definition

Clickjacking is a user-interface deception attack that overlays or disguises a trusted action so a person clicks something different from what they perceive. In NHI and IAM workflows, the risk is not usually theft of the secret itself, but the misuse of an intended approval, consent, or autofill action in the wrong application context. This makes it especially relevant for browser-based admin portals, OAuth consent screens, password managers, and delegated approval flows where a human action can trigger access on behalf of an NHI.

Definitions vary across vendors when clickjacking is discussed alongside UI redressing, iframe abuse, or consent phishing. The practical distinction is that clickjacking depends on visual misdirection and an unintended click path, while the downstream impact may be credential exposure, privilege escalation, or unauthorized workflow completion. For a broader security posture, NIST frames this kind of risk within protective controls that preserve trust in access pathways, as reflected in the NIST Cybersecurity Framework 2.0. The most common misapplication is treating clickjacking as only a web UI issue, which occurs when teams ignore its effect on identity approvals and delegated admin actions.

Examples and Use Cases

Implementing defenses against clickjacking rigorously often introduces friction in user experience, requiring organisations to weigh safer interaction design against convenience in high-trust workflows.

• A malicious page frames a cloud console button so an operator unknowingly approves an NHI role assignment in an embedded window.
• An attacker manipulates a password manager prompt, causing an autofill action to occur on a lookalike page rather than the intended login context.
• A delegated approval screen for API key issuance is hidden behind transparent overlays, leading a reviewer to click grant instead of deny.
• A SOC analyst reviewing the Ultimate Guide to NHIs can map clickjacking risk to identity workflows where a single mistaken click has lasting access consequences.
• Browser-level protections, frame restrictions, and explicit confirmation steps are often paired with guidance from the NIST Cybersecurity Framework 2.0 to reduce UI deception exposure.

Why It Matters in NHI Security

Clickjacking matters because NHI security is frequently mediated by human action, even when the underlying identity is non-human. If a service account is approved, a token is authorized, or a secret-management action is confirmed in the wrong context, the result can be standing access that persists far beyond the moment of deception. NHIMG reports that Ultimate Guide to NHIs finds 97% of NHIs carry excessive privileges, which means a single mistaken approval can unlock far more access than intended. That is why clickjacking should be treated as a governance issue, not just a browser hardening issue.

It also intersects with secrets handling and trust boundaries. When operators rely on visual confirmation alone, they can approve actions that bypass intended review, especially in portals that manage tokens, certificates, or automated agents. Organisations typically encounter the operational impact only after an unexpected permission grant, unsafe consent, or suspicious automation event, at which point clickjacking becomes unavoidable to address.