X-Frame Options & Clickjacking Protection

TL;DR

Using X-Frame-Options, Content-Security-Policy: frame-ancestors and Referrer-Policy headers is a good start to prevent clickjacking (a type of Cross-Frame Scripting attack), but it’s not always enough. You need to understand what each header does, how they interact, and consider modern browser features like sandboxing for complete protection.

Understanding the Threat: Clickjacking

Clickjacking tricks users into clicking something different from what they perceive, often by embedding a legitimate webpage within an invisible iframe. This can lead to unwanted actions like liking social media posts, changing account settings or making purchases without their knowledge. These attacks rely on the browser allowing your site to be loaded inside another website’s frame.

The Headers & How They Help

1. X-Frame-Options: This header tells the browser whether it’s allowed to display your page in a frame. It has three main values:
   • DENY: Completely prevents framing of your page. This is generally the most secure option if you don’t need framing.

     X-Frame-Options: DENY

   • SAMEORIGIN: Allows framing only from pages on the same domain as yours.

     X-Frame-Options: SAMEORIGIN

   • ALLOW-FROM uri: (Deprecated and not widely supported) Allows framing only from a specific URI. Avoid using this due to compatibility issues.
2. Content-Security-Policy (CSP): frame-ancestors directive This is the modern replacement for X-Frame-Options, offering more flexibility and control. It defines which origins are allowed to embed your page in a frame.
   • frame-ancestors 'none': Similar to X-Frame-Options: DENY – prevents framing from any origin.

     Content-Security-Policy: frame-ancestors 'none'

   • frame-ancestors 'self': Similar to X-Frame-Options: SAMEORIGIN – allows framing only from the same domain.

     Content-Security-Policy: frame-ancestors 'self'

   • frame-ancestors example.com *.example.com: Allows framing from specific domains and subdomains.

     Content-Security-Policy: frame-ancestors example.com *.example.com

3. Referrer-Policy: While not directly preventing clickjacking, this header controls how much referrer information is sent when your page is loaded in a frame. Setting it to strict-origin-when-cross-origin or similar can limit the attacker’s ability to gather useful information about the user.

   Referrer-Policy: strict-origin-when-cross-origin

Why Four Headers Might Not Be Enough

1. Browser Compatibility: Older browsers may not fully support CSP. X-Frame-Options has better compatibility, but it’s being phased out.
2. Misconfiguration: A mistake in your CSP rules (e.g., allowing too broad an origin) can create vulnerabilities.
3. Subdomain Issues: Carefully consider how subdomains are handled. If you allow framing from ‘self’, it includes all subdomains, which might not be what you intend.
4. Sandboxing (iframe): Attackers can sometimes bypass these headers using advanced techniques or by exploiting vulnerabilities in the iframe itself. Using the sandbox attribute on iframes adds an extra layer of security.

   <iframe sandbox="allow-scripts allow-same-origin" src="https://example.com/">

   The `sandbox` attribute restricts what the iframe can do (e.g., prevent scripts, forms, cookies).

5. HTTP Strict Transport Security (HSTS): Ensure your site uses HSTS to force HTTPS connections. Clickjacking attacks are easier over insecure HTTP.

Practical Steps for Better Protection

1. Use CSP: Prioritise using Content-Security-Policy with the frame-ancestors directive, and test it thoroughly.
2. Fallback to X-Frame-Options: Include X-Frame-Options: DENY as a fallback for older browsers.
3. Set Referrer-Policy: Use a restrictive referrer policy like strict-origin-when-cross-origin.
4. Regular Audits: Regularly review your CSP configuration and test your site for clickjacking vulnerabilities using online tools or penetration testing.
5. Sandboxing: If you *must* use iframes, apply the appropriate `sandbox` attributes to limit their capabilities.