In modern web application security, protecting your users from credential theft and unauthorized actions is of vital importance. Among the many client-side vulnerabilities, clickjacking (also known as UI redressing) represents a significant threat. Implementing a robust clickjacking defense prevents attackers from overlaying transparent frames to hijack user clicks.
In this guide, we will outline a practical clickjacking defense cheat sheet, detail the configuration steps for security headers, and discuss modern web browser policies.
What is Clickjacking?
Clickjacking is a malicious technique where an attacker loads a legitimate, target website inside an invisible iframe (using opacity: 0 in CSS) on a malicious website. An attacker then overlays dummy buttons directly over the target website’s action elements. When a user clicks what appears to be a harmless button, they are actually clicking the hidden element on the target site (such as a “Delete Account” or “Buy Now” button).
The Clickjacking Defense Cheat Sheet
To secure your web applications, follow these three essential steps:
Step 1: Configure Content Security Policy (CSP) frame-ancestors
The modern and most robust defense against clickjacking is the frame-ancestors directive, part of the Content Security Policy (CSP) header. This header tells the browser which parent domains are allowed to frame your page.
To restrict framing to only your own domain, send this HTTP response header:
Content-Security-Policy: frame-ancestors 'self';If you are running an **Nginx** server, configure it in your server blocks:
add_header Content-Security-Policy "frame-ancestors 'self';" always;Step 2: Enforce the X-Frame-Options Header (Legacy Support)
Because some older web browsers (like Internet Explorer) do not support the CSP frame-ancestors directive, you should also send the legacy X-Frame-Options header. It accepts two primary values:
- DENY: Prevents any website, including your own, from framing the page.
- SAMEORIGIN: Only allows the page to be framed if the parent site has the exact same origin.
To configure X-Frame-Options in **Apache**, add this line to your .htaccess or virtual host file:
Header always set X-Frame-Options "SAMEORIGIN"Step 3: Implement JavaScript Frame-Busting (Fallback)
If headers cannot be sent (for example, on static HTML pages hosted on legacy environments), you can use a client-side JavaScript frame-busting script. This script checks if the page is inside an iframe, and if so, forces the browser window to break out:
<script>
if (self !== top) {
top.location = self.location;
}
</script>Defense Headers Comparison Table
Refer to this table to compare security header properties:
| Header Name | Directives / Values | Browser Support | Security Level |
|---|---|---|---|
| Content-Security-Policy | frame-ancestors 'self' | Modern Browsers | Excellent (Highly Customizable) |
| X-Frame-Options | DENY / SAMEORIGIN | All (Including Legacy) | Good (Basic restriction) |
| JS Frame-Busting | Client-side script fallback | Varies (can be disabled via sandbox) | Weak (Easy to bypass) |
Summary
Securing your web app with a proper **clickjacking defense** requires configuring both CSP and X-Frame-Options headers on your web servers. This multi-layered defense ensures your site remains protected across both legacy and modern browsers. To understand how secure hosting solutions deploy these configurations, read our overview on Cloud Computing and Its Key Properties. For advanced remediation methods, visit the official OWASP Clickjacking Defense Cheat Sheet Series.
Leave a comment