Clickjacking in Aspnet with Mutual Tls

Clickjacking is a client-side attack that tricks a user into interacting with a hidden or disguised UI element inside an iframe. In an ASP.NET application protected by Mutual TLS (mTLS), the presence of mTLS does not prevent clickjacking, because mTLS secures the transport layer between client and server and does not enforce how the response is rendered or embedded by browsers. An attacker can host a malicious page that loads your ASP.NET endpoint in an invisible iframe and overlay interactive controls, leading to unauthorized actions such as changing settings or making requests on behalf of the authenticated user.

When mTLS is used, the server validates the client certificate during the TLS handshake. This ensures strong authentication of the client to the server, but it does not change the browser’s same-origin policy behavior or Content Security Policy (CSP) settings. If your ASP.NET responses do not explicitly prevent framing via X-Frame-Options or Content-Security-Policy: frame-ancestors, the endpoint remains embeddable regardless of mTLS. In practice, this means an mTLS-protected API endpoint that returns HTML or serves a page can still be abused in clickjacking scenarios if the browser is tricked into loading it as an embedded resource.

For example, an ASP.NET Core endpoint that serves a dashboard over HTTPS with mTLS might include a form to perform state-changing operations. An attacker can craft a page that embeds that dashboard URL inside an iframe, sets the iframe to cover a button with a sensitive action, and style it to be invisible. The user’s click on a benign element on the attacker’s page results in an unintended request issued by the browser to the mTLS-protected endpoint, because the browser sends the client certificate and cookies as part of the request. This shows that while mTLS strengthens authentication, it does not mitigate UI redressing; you still need explicit anti-clickjacking headers and CSP rules.

Scanning an ASP.NET endpoint with middleBrick will surface missing anti-clickjacking protections under its security checks, even when mTLS is in place. middleBrick’s checks include input validation, authentication, and property authorization, and it maps findings to frameworks such as OWASP API Top 10 and provides prioritized remediation guidance. By integrating middleBrick into your workflow via the CLI (middlebrick scan <url>) or the GitHub Action, you can detect whether your endpoints expose a clickjacking surface despite using mTLS, and receive actionable guidance.

To remediate clickjacking in ASP.NET while using Mutual TLS, you must enforce anti-framing headers and strict CSP. These headers instruct browsers not to allow your pages to be embedded, independent of the strength of your TLS client certificate validation. Below are concrete code examples for an ASP.NET Core application that enforces both X-Frame-Options and Content-Security-Policy frame-ancestors, alongside a minimal mTLS server configuration.

Enabling Mutual TLS in ASP.NET Core

Configure Kestrel to require client certificates. This ensures that only clients presenting a trusted certificate can establish a successful TLS connection.

// Program.cs
var builder = WebApplication.CreateBuilder(args);

builder.WebHost.ConfigureKestrel(serverOptions =>
{
    serverOptions.ListenAnyIP(5001, listenOptions =>
    {
        listenOptions.UseHttps(httpsOptions =>
        {
            httpsOptions.ServerCertificate = new X509Certificate2("server.pfx", "password");
            httpsOptions.ClientCertificateMode = ClientCertificateMode.RequireCertificate;
            // Optionally validate client certificate thumbprint or chain
            httpsOptions.ClientCertificateValidation = (cert, chain, sslPolicyErrors) =>
            {
                if (cert is null) return false;
                // Example: validate thumbprint
                var allowedThumbprint = "A1B2C3D4E5F6...";
                return cert.Thumbprint?.Replace(" ", "") == allowedThumbprint;
            };
        });
    });
});

// Anti-clickjacking headers
app.Use(async (context, next) =>
{
    context.Response.Headers["X-Frame-Options"] = "DENY";
    // Alternatively: "SAMEORIGIN" if embedding by same origin is needed
    context.Response.Headers["Content-Security-Policy"] = "frame-ancestors 'none'";
    await next();
});

app.Run((context) =>
{
    return context.Response.WriteAsync("Secure endpoint with mTLS and anti-clickjacking headers");
});

app.Run();

Additional protections in ASP.NET MVC or Razor Pages

If you use MVC or Razor Pages, you can also add headers via middleware or in Startup.cs/Program.cs. The following snippet shows adding headers globally and for specific controllers or actions.

// Program.cs with global policy and endpoint-specific handling
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddControllersWithViews();
var app = builder.Build();

app.Use(async (context, next) =>
{
    context.Response.Headers.XFrameOptions = "DENY";
    context.Response.Headers["Content-Security-Policy"] = "frame-ancestors 'none'";
    await next();
});

app.UseHttpsRedirection();
app.UseStaticFiles();
app.UseRouting();
app.UseAuthorization();
app.MapControllerRoute(
    name: "default",
    pattern: "{controller=Home}/{action=Index}/{id?}");

app.Run();

For controller-level control, you can add a filter to set headers for specific actions:

[AttributeUsage(AttributeTargets.Class | AttributeTargets.Method)]
public class AntiClickjackingAttribute : ActionFilterAttribute
{
    public override void OnResultExecuting(ResultExecutingContext context)
    {
        context.HttpContext.Response.Headers["X-Frame-Options"] = "DENY";
        context.HttpContext.Response.Headers["Content-Security-Policy"] = "frame-ancestors 'none'";
        base.OnResultExecuting(context);
    }
}

// Usage on a controller or action
[AntiClickjacking]
public class DashboardController : Controller
{
    public IActionResult Index() => View();
}

When using these headers, ensure they do not conflict with legitimate embedding needs. If you must allow framing from specific origins, set frame-ancestors to a controlled list instead of 'none'. Testing with middleBrick can help verify that headers are correctly applied and that your endpoints are not inadvertently exposed to clickjacking despite mTLS.