Modern websites are not only about beautiful UI and animations security matters too.
One of the most common browser-based attacks is called Clickjacking.
Even frontend developers should understand it because this attack targets the UI itself.
🛡️ What is Clickjacking?
Clickjacking is a type of attack where a malicious website tricks users into clicking something they cannot see.
Usually, the attacker places your website inside an invisible <iframe> and overlays fake buttons or content on top of it.
The user thinks they are clicking one thing…
but they are actually clicking buttons on your real website underneath.
⚠️ Real Example
Imagine this:
A user visits a fake website with a “Play Video” button.
But behind that button, your banking website is loaded invisibly inside an iframe.
When the user clicks “Play Video” they might actually:
- transfer money
- change account settings
- enable permissions
- delete data
without realizing it.
🧠Why It’s Dangerous
Clickjacking can:
- trick users into performing actions
- steal interactions
- bypass user intention
- abuse trusted websites
In some advanced cases, attackers can even capture keyboard input or sensitive interactions.
đź”’ Modern Protection Methods
Modern browsers provide built-in defenses.
1. X-Frame-Options Header
This HTTP header controls whether your website can be embedded inside an iframe.
Block all framing
X-Frame-Options: DENY
Allow only your own website
X-Frame-Options: SAMEORIGIN
This is the most common option.
2. Content Security Policy (Recommended)
Today, most developers prefer using CSP.
Content-Security-Policy: frame-ancestors 'self';
This tells the browser:
“Only allow this website to be framed by itself.”
You can also allow specific domains:
Content-Security-Policy: frame-ancestors 'self' https://example.com;
⚠️ Important Note
Older browsers handled clickjacking differently.
Some legacy protections used JavaScript frame-busting techniques like this:
<script>
if (self !== top) {
top.location = self.location;
}
</script>
But modern security headers are much more reliable.
âś… Best Practice
For modern applications:
- Use
Content-Security-Policy - Add
frame-ancestors - Avoid unnecessary iframes
- Protect sensitive actions with confirmation steps
Final Thoughts
Frontend security is not only the backend developer’s responsibility.
Even UI decisions can become security vulnerabilities.
Understanding attacks like Clickjacking helps developers build safer and more trustworthy web applications.
Top comments (6)
What about applications that legitimately need to be embedded in an iframe, like dashboards or admin widgets? How do you balance clickjacking protection with those integration requirements?
frame-ancestorswith explicit allowed origins handles that case cleanly, but the interesting problem shows up in multi-tenant SaaS — when each customer dynamically whitelists their own embed domain, the CSP header gets generated per-request from a database. If an attacker signs up as a customer and adds their domain to that whitelist, they bypass iframe protection through the front door. For admin widgets specifically, switching topostMessagewith strict origin validation on the receiving end sidesteps the clickjacking surface entirely since nothing gets framed.Thanks @circuit , that’s a really valuable addition especially the multi-tenant SaaS example. I didn’t mention that angle in the article and it shows how iframe protection can become an access-control issue when origins are dynamically trusted.
The point about using
postMessagewith strict origin validation for admin widgets is also great. Definitely adding more notes about that in future security posts.That makes sense. The multi tenant case is where this gets tricky since trust decisions move into runtime data. The postMessage approach also feels safer for admin style widgets since it removes framing entirely.
Do you like to cover more about web security ?
yah man