top of page

Clickjacking: UI Redressing Risks and Defenses

Sep 11
2 min read

Clickjacking sounds retro—like something from forums next to 'hack Facebook.' It still shows up when sensitive actions lack frame busting and modern CSP.


The idea is simple: trick a user into clicking something they didn't intend while looking at your decoy page. For testers, the job is proving whether high-impact actions are frameable.


Clickjacking: UI Redressing Risks and Defenses

Clickjacking persists because framing policies are boring config—testers who document user-visible impact help prioritize fixes.



When it's worth chasing


Account settings changes, payment confirmations, OAuth approvals, and admin toggles on apps without `X-Frame-Options` or restrictive `frame-ancestors`.


Mobile web views and embedded widgets sometimes inherit weaker policies than the main site.



High-level validation


On authorized targets, check whether sensitive endpoints can be embedded cross-origin. Note whether CSRF tokens alone would block the action anyway.


  • Review CSP reports if clients collect them

  • Compare behavior logged-in vs logged-out

  • Document user interaction required—impact drives severity



Defenses that work


`frame-ancestors` in CSP, explicit XFO, and requiring re-auth for destructive actions. SameSite cookies reduce some combo attacks but aren't a clickjack fix alone.


Clickjacking is often informational alone—pair with another bug for a chain story.


Demo only with test accounts you control on in-scope pages.


Verify framing fixes on mobile browsers separately—desktop CSP patches miss webview wrappers surprisingly often.



Mobile webviews


Hybrid apps wrapping web checkout in webviews sometimes inherit permissive framing—compare native vs mobile web behavior.


Drag-and-drop sensitive actions need stricter framing policy than static pages.



Combo documentation


Note if sensitive actions lack re-auth even when framed—severity climbs with account takeover chains.


Some browsers treat iframe policies differently; test the browsers in scope statements.


Recommend security headers on all embeddable pages, not just login.




Worth reading next


Web Hacking for Pentesters: Cross-Site Request Forgery (CSRF)


CORS, postMessage, and Origin Mistakes in Modern Web Apps


Penetration Testing: Web Application Checklist (WAPT)

Comments


© 2022 by SapiensHack.com (Security)

bottom of page