Clickjacking in Aspnet with Bearer Tokens

Clickjacking in ASP.NET applications that use Bearer Tokens can expose protected endpoints to unauthorized actions when token handling is combined with UI rendering and missing anti-clickjacking controls. In this scenario, an authenticated user’s request includes a Bearer Token in the Authorization header, and the application embeds sensitive functionality behind endpoints that rely solely on token presence rather than additional UI-level protections.

An attacker can craft a malicious page that loads the vulnerable ASP.NET page inside an invisible iframe or overlay, tricking a user who is logged in and possesses a valid Bearer Token into performing unintended operations. Because the browser automatically includes cookies and may include cached Authorization headers, requests initiated from the embedded context can execute with the user’s privileges. If the ASP.NET application does not validate the Origin or Referer headers and does not enforce frame-embedding restrictions, the token-bound request completes successfully from the victim’s session, leading to unauthorized state changes such as changing email, updating profile settings, or invoking administrative APIs.

This combination is particularly risky when token-based authentication is used without additional UI-level safeguards. For example, an endpoint like /api/users/change-email that accepts a Bearer Token and performs a state-changing PUT without ensuring the request originates from a trusted UI context can be abused. The OWASP API Top 10 category on Broken Object Level Authorization (BOLA) intersects with clickjacking when object-level access controls are bypassed via the UI layer. Insecure embedding of API-driven pages, lack of X-Frame-Options, and missing Content Security Policy frame-ancestors directives allow the attacker’s page to control the visual context while the token silently authorizes the operation.

ASP.NET applications that render Razor pages or MVC views and also expose token-protected APIs must consider both web and API security practices. If anti-forgery tokens are used for MVC forms but not enforced for API calls, or if CORS policies are misconfigured to allow broad origins, the attack surface expands. The presence of a Bearer Token does not prevent the browser from making requests to your origin; it only authenticates them. Therefore, without explicit anti-clickjacking defenses, an attacker can coerce the victim’s browser into sending authenticated requests that appear legitimate to the server.

To identify this risk during a scan, tools like middleBrick evaluate whether responses include frame-embedding protections and whether token-requiring endpoints are reachable from embedded contexts. Proper remediation requires coordinated defenses at the web UI and API layers, ensuring that sensitive actions require explicit user consent beyond token possession and that pages cannot be embedded by untrusted origins.

Remediation focuses on preventing your ASP.NET pages from being embedded and ensuring that Bearer Token usage does not bypass UI-level authorization checks. Implement HTTP response headers to prohibit framing, enforce anti-forgery validation for state-changing operations, and design API endpoints to require explicit context beyond token presence.

1. Prevent framing with security headers

Configure your ASP.NET application to send X-Frame-Options and Content-Security-Policy headers. This prevents browsers from rendering your pages inside iframes on attacker-controlled sites.

// In Startup.cs or Program.cs
app.Use(async (context, next) =>
{
    context.Response.Headers.Add("X-Frame-Options", "DENY");
    context.Response.Headers.Add("Content-Security-Policy", "frame-ancestors 'none'");
    await next.Invoke();
});

2. Use anti-forgery tokens for state-changing UI actions

For MVC views that perform state changes, validate anti-forgery tokens in addition to Bearer Token validation. This ensures that requests originate from your own forms and not from forged requests embedded elsewhere.

<form method="post">
    <input name="__RequestVerificationToken" type="hidden" value="">
    <button type="submit">Update</button>
</form>

In the controller:

[HttpPost]
[ValidateAntiForgeryToken]
public async Task<IActionResult> ChangeEmail(ChangeEmailModel model)
{
    if (!ModelState.IsValid)
    {
        return View(model);
    }
    // Perform change after anti-forgery and user confirmation checks
    return RedirectToAction("Profile");
}

3. Validate Origin and Referer for sensitive API endpoints

For API endpoints that accept Bearer Tokens, add origin validation to ensure requests come from trusted sources. This adds a layer of defense against cross-origin forged requests.

app.Use(async (context, next) =>
{
    var allowedOrigins = new[] { "https://yourapp.com" };
    var origin = context.Request.Headers["Origin"].ToString();
    var referer = context.Request.Headers["Referer"].ToString();

    if (!string.IsNullOrEmpty(origin) && !allowedOrigins.Contains(origin))
    {
        context.Response.StatusCode = 403;
        return;
    }
    // Optionally validate Referer similarly
    await next.Invoke();
});

4. Require explicit user interaction for sensitive operations

Design your UI so that sensitive operations, such as changing authentication factors or email, require a separate confirmation step that is not triggered automatically via JavaScript from an embedded page. Do not rely on the presence of a Bearer Token alone to authorize destructive actions.

5. Secure token storage and transmission

Ensure Bearer Tokens are transmitted over HTTPS and stored securely on the client (e.g., in memory or secure storage). Avoid embedding tokens in URLs or local storage where they may be exposed to cross-site scripting, which can compound clickjacking risks.

6. Use middleBrick to validate your defenses

After implementing these measures, use the middleBrick CLI to verify that headers are present and that sensitive endpoints are not trivially embeddable. Scan from terminal with middlebrick scan <url> to obtain a security risk score and findings specific to authentication, BOLA, and input validation checks.

For ongoing assurance, the Pro plan enables continuous monitoring and CI/CD integration via the GitHub Action, which can fail builds if risk scores drop below your defined threshold. The Dashboard lets you track how your API security scores evolve as you apply these fixes.