Clickjacking tricks a person into clicking a hidden or disguised control, so the browser performs an action that person did not mean to approve.
The click itself is real and human, which separates this trick from fake advertising clicks generated to drain a budget.
How it works
A page the person trusts, or thinks they understand, is arranged so the visible button is not the control that receives the click, and that action might change a setting or start a purchase where the person is already signed in.
The harm is misplaced consent, not a stolen password by itself.
Browsers and sites can refuse to be framed by strangers, and sensitive actions can ask for a fresh confirmation that a hidden layer cannot silently supply.
Interface changes that surprise people, especially around payments and permissions, deserve the same care as server side checks.
Concrete examples
- A person thinks they are closing a coupon banner and instead approves a permission on a site where they were already signed in.
- A game page hides a payment confirmation under a visible play button, and the next screen shows an unexpected charge.
- A settings page that refuses to be embedded in another site stops a stranger from overlaying its buttons.
Protective measures
- Refuse to let untrusted sites embed your sensitive pages, and test that payment and permission screens enforce that refusal.
- Ask for a fresh, visible confirmation on high impact actions so a hidden layer cannot supply the approval alone.
- Review new interface layouts for controls that can be covered, shifted, or made transparent while still receiving clicks.
- Teach support staff to ask whether a person remembers the confirmation screen, because a confused click is a different case from a stolen password.