Cross Site Request Forgery in Aspnet (Csharp)

Cross Site Request Forgery (CSRF) in ASP.NET with C# occurs when an authenticated user is tricked into submitting an unwanted request on a web application where their identity is already validated. Because ASP.NET relies on cookies for authentication (e.g., the .AspNetCore.Cookies cookie), and by default many endpoints assume a request bearing a valid session cookie is intentional, CSRF becomes viable when anti-forgery protections are absent or misapplied.

In classic ASP.NET MVC and Razor Pages, the framework provides built-in anti-forgery features via the ValidateAntiForgeryToken attribute and the @Html.AntiForgeryToken helper. However, if developers omit these on state-changing endpoints (POST/PUT/DELETE), or disable antiforgery in configuration, the application becomes susceptible. For example, an endpoint like /api/account/update-email that accepts a JSON payload and relies solely on cookie-based authentication without verifying the origin or an anti-forgery token can be invoked from a malicious site via a crafted form or script. Browsers automatically include cookies for the target domain, enabling the forged request to execute with the victim’s privileges. This is especially risky in ASP.NET applications that expose both browser-rendered views and API-style endpoints using C# controllers, where inconsistent protections across action methods create a weak link.

Modern SPAs consuming ASP.NET APIs via C# backend for data exchange add another layer of risk: if the API does not validate the Origin header or implement anti-CSRF tokens for non-browser clients, a compromised frontend or a malicious site can drive authenticated requests. The combination of cookie-based auth, missing anti-forgery validation, and complex C# controller logic (e.g., [FromBody] models that bind automatically) increases the chance that an oversight leads to a vulnerable endpoint. Attack patterns include forged transfers, email changes, or unauthorized state updates, which map to OWASP API Top 10 2023 A5 (Broken Function Level Authorization) when authorization checks are also weak.

Remediate CSRF in ASP.NET with C# by combining anti-forgery tokens, strict origin checks, and secure cookie settings. For MVC and Razor Pages, always use the ValidateAntiForgeryToken attribute on state-changing actions and include the token in forms.

@using (Html.BeginForm("UpdateEmail", "Account", FormMethod.Post))
{
    @Html.AntiForgeryToken()
    
    Update
}

On the server, ensure the attribute is applied:

[HttpPost]
[ValidateAntiForgeryToken]
public IActionResult UpdateEmail(UpdateEmailModel model)
{
    // safe update logic
    return RedirectToAction("Index");
}

For ASP.NET Core APIs consumed by browsers, enable anti-forgery for endpoints that accept cookie auth and add custom policies to validate the Origin header. In Program.cs (or Startup.cs), configure services and middleware:

builder.Services.AddAntiforgery(options =>
{
    options.HeaderName = "X-XSRF-TOKEN";
});

var app = builder.Build();
app.UseAntiforgery();
app.Use(async (context, next) =>
{
    if (context.Request.Method == HttpMethods.Post)
    {
        // basic origin check as an additional layer
        if (!context.Request.Headers.TryGetValue("Origin", out var origin))
        {
            context.Response.StatusCode = 403;
            return;
        }
        // optionally validate against a known list of origins
    }
    await next(context);
});

Secure authentication cookies to mitigate the impact of CSRF where tokens are absent:

builder.Services.ConfigureApplicationCookie(options =>
{
    options.Cookie.SameSite = SameSiteMode.Strict;
    options.Cookie.SecurePolicy = CookieSecurePolicy.Always;
    options.Cookie.HttpOnly = true;
});

Adopt these measures consistently across C# controllers and endpoints. For API-specific routes, consider requiring a custom header (e.g., X-Requested-With) in addition to anti-forgery tokens. The middleBrick CLI (middlebrick scan <url>) can verify whether anti-CSRF protections are present across your ASP.NET endpoints and flag missing ValidateAntiForgeryToken usage or insecure cookie attributes as part of your security posture.