Skip to main content

Insecure or unset HTTP headers - X-Frame Options

Need​

Implementation of secure and properly configured HTTP headers

Context​

  • Usage of C# for developing robust and efficient software applications
  • Usage of Microsoft.AspNetCore.Builder for configuring and building ASP.NET Core applications
  • Usage of Microsoft.AspNetCore.Hosting for hosting ASP.NET Core applications
  • Usage of Microsoft.AspNetCore.Http for handling HTTP requests and responses in ASP.NET Core applications

Description​

Non compliant code​

using System;
using Microsoft.AspNetCore.Builder;
using Microsoft.AspNetCore.Hosting;
using Microsoft.AspNetCore.Http;

public class Startup
{
    public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
    {
        app.Use(async (context, next) =>
        {
            context.Response.Headers.Add("X-Frame-Options", "SAMEORIGIN");
            await next();
        });

        app.Run(async (context) =>
        {
            await context.Response.WriteAsync("Hello World!");
        });
    }
}

The above code represents a basic ASP.NET Core application with a middleware that sets the "X-Frame-Options" header to "SAMEORIGIN". This header is used as a security mechanism to prevent the application from being embedded within an iframe on another domain (clickjacking attack).

The middleware is configured in the Configure method of the Startup class. It adds the "X-Frame-Options" header to every response that the application sends.

However, the use of the "X-Frame-Options" header is now considered deprecated. Its protection can be bypassed using several iframe layers. This means that an attacker could potentially still embed the application within an iframe and perform a clickjacking attack.

Therefore, relying solely on the "X-Frame-Options" header for clickjacking protection presents a security vulnerability in the application.

Steps​

  • Replace the use of X-Frame-Options header with Content-Security-Policy header.
  • Set the Content-Security-Policy header to include 'frame-ancestors' directive with 'self' or specific domains to allow framing from trusted sources only.
  • Remove the use of X-Frame-Options header from the response headers.

Compliant code​

using System;
using Microsoft.AspNetCore.Builder;
using Microsoft.AspNetCore.Hosting;
using Microsoft.AspNetCore.Http;

public class Startup
{
    public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
    {
        app.Use(async (context, next) =>
        {
            context.Response.Headers.Add("Content-Security-Policy", "frame-ancestors 'self'");
            await next();
        });

        app.Run(async (context) =>
        {
            await context.Response.WriteAsync("Hello World!");
        });
    }
}

The updated code replaces the deprecated X-Frame-Options header with the Content-Security-Policy header. The Content-Security-Policy header is a more modern and secure way to control which domains can embed your content using <iframe>, <object>, <embed>, and <applet>.

The frame-ancestors 'self' directive is added to the Content-Security-Policy header. This directive specifies which sources are allowed to embed the current page. This is similar to the X-Frame-Options header, but with more granularity. The 'self' keyword means that only the same origin can embed the current page.

The X-Frame-Options header is removed from the response headers, as it is no longer needed with the Content-Security-Policy header in place.

This change helps to protect the application against clickjacking attacks by ensuring that the content can only be embedded from trusted sources.

References​

Last updated on