Anti-clickjacking Header

Anti-clickjacking is a security mechanism that protects web applications from clickjacking attacks. If your web application has been flagged for an Anti-clickjacking Header vulnerability, it means that your application is not sending the appropriate HTTP response headers to protect against clickjacking attacks.

Anti-clickjacking is a security mechanism that protects web applications from clickjacking attacks, which involve deceiving a user into clicking on a malicious link or button by overlaying it with a legitimate-looking element. Anti-clickjacking headers are HTTP response headers that instruct the user's web browser to prevent clickjacking attacks by restricting how the application can be embedded or framed within other web pages.

If your web application has been flagged for an Anti-clickjacking Header vulnerability, it means that your application is not sending the appropriate HTTP response headers to protect against clickjacking attacks. This vulnerability can be fixed by adding the required headers to the application's HTTP response.

In this guide, we'll walk through the steps to fix the Anti-clickjacking Header vulnerability in your web application.

Step 1: Understand the vulnerability

Before we begin, it's important to understand what Anti-clickjacking Header vulnerability is and how it can be exploited. Clickjacking is a type of attack where an attacker tricks a user into clicking on a button or link that appears to be legitimate but is actually a trap. This is usually done by overlaying the legitimate-looking button or link with an invisible frame or layer, which captures the user's click and performs an action that the user did not intend to perform.

Anti-clickjacking headers are HTTP response headers that can prevent clickjacking attacks by instructing the user's web browser to restrict how the application can be embedded or framed within other web pages. These headers include the X-Frame-Options header and the Content-Security-Policy header.

The X-Frame-Options header instructs the browser to prevent the application from being embedded in a frame or iframe on other domains. The Content-Security-Policy header provides more granular control over how the application can be embedded, allowing you to specify which domains are allowed to embed the application and which types of embedding are allowed.

Step 2: Add X-Frame-Options header

To add the X-Frame-Options header to your application, you need to modify your server configuration to include the header in the HTTP response. The header should be included in every response sent by the server to the client.

Example for Apache server

To add the X-Frame-Options header to an Apache server, add the following line to your .htaccess file:

Header always append X-Frame-Options SAMEORIGIN

This line will append the X-Frame-Options header to every HTTP response sent by the server, with the value "SAMEORIGIN". This means that the application can only be embedded in a frame or iframe on the same domain as the application itself.

Example for Nginx server

To add the X-Frame-Options header to an Nginx server, add the following line to your nginx.conf file:

add_header X-Frame-Options SAMEORIGIN;

This line will add the X-Frame-Options header to every HTTP response sent by the server, with the value "SAMEORIGIN".

Step 3: Add Content-Security-Policy header

To add the Content-Security-Policy header to your application, you need to modify your server configuration to include the header in the HTTP response. The header should be included in every response sent by the server to the client.

Example for Apache server

To add the Content-Security-Policy header to an Apache server, add the following line to your .htaccess file:

Header always set Content-Security-Policy "frame-ancestors 'self';"

This line will set the Content-Security-Policy header to every HTTP response sent by the server, with the value "frame-ancestors 'self';". This means that the application can only be embedded in a frame or iframe on the same domain as the application itself.

Example for Nginx server

To add the Content-Security-Policy header to an Nginx server, add the following line to your nginx.conf file:

add_header Content-Security-Policy "frame-ancestors 'self';";

This line will add the Content-Security-Policy header to every HTTP response sent by the server, with the value "frame-ancestors 'self';".

Step 4: Test the changes

After adding the X-Frame-Options and Content-Security-Policy headers to your application, it's important to test the changes to ensure that they are working as expected.

Testing with a browser

To test the changes using a web browser, open the developer tools in your browser and navigate to the Network tab. Reload your application and inspect the headers for each response. You should see the X-Frame-Options and Content-Security-Policy headers in the response headers.

Testing with a vulnerability scanner

You can also use a vulnerability scanner to test the changes. Rescan your application with the same vulnerability scanner that flagged the Anti-clickjacking Header vulnerability. The scanner should no longer flag the vulnerability if the headers are correctly implemented.

Conclusion

In this guide, we walked through the steps to fix the Anti-clickjacking Header vulnerability in your web application. By adding the X-Frame-Options and Content-Security-Policy headers to your application's HTTP response, you can prevent clickjacking attacks and ensure that your application is secure. It's important to test the changes after implementing them to ensure that they are working as expected.

Achieve SOC2 Compliance

We make your startup SOC2 compliant by implementing and managing the required security controls for you.

Get Started