Cross Site Request Forgery (CSRF)¶

What does this mean ?¶

CSRF occurs when a browser is induced to send a state-changing request using credentials it attaches automatically, such as session cookies. The server cannot assume that a request was intentionally initiated from its own interface merely because the user is signed in.

What can happen ?¶

An unwanted request can change account settings or perform other actions available to the current user. The attacker does not necessarily need to read the response. Login, recovery and administrative flows also deserve review; do not limit the threat model to a single payment form.

Recommendation¶

Use the framework's current CSRF protection and validate a session-bound token for state-changing requests. Never use GET for operations such as deletion or password changes. Keep tokens out of URLs and logs. Validate origin/fetch metadata where appropriate and set suitable Secure, HttpOnly and SameSite session-cookie attributes.

SameSite cookies and CORS are additional controls, not universal replacements for token validation. An API that exclusively accepts a bearer token explicitly added in the Authorization header has a different CSRF threat model from a cookie-authenticated API. Verify every accepted credential path before exempting it. XSS can defeat many CSRF controls, so safe output handling remains necessary.

Sample Code¶

These fragments assume an existing authentication and session setup. They show the CSRF layer only; resource authorization and request validation still belong to the handler.

from django.contrib.auth.decorators import login_required
from django.http import HttpResponse
from django.views.decorators.http import require_POST

@login_required
@require_POST
def update_preferences(request):
    # Validate fields and authorize the update here.
    return HttpResponse(status=204)

<form method="post" action="/preferences/">
  {% csrf_token %}
  <button type="submit">Save preferences</button>
</form>

@org.springframework.context.annotation.Bean
org.springframework.security.web.SecurityFilterChain webSecurity(
        org.springframework.security.config.annotation.web.builders.HttpSecurity http)
        throws Exception {
    http.csrf(org.springframework.security.config.Customizer.withDefaults())
        .authorizeHttpRequests(auth -> auth.anyRequest().authenticated());
    return http.build();
}

builder.Services.AddControllersWithViews(options =>
    options.Filters.Add(new Microsoft.AspNetCore.Mvc.AutoValidateAntiforgeryTokenAttribute()));

<form method="post" action="/preferences">
    @Html.AntiForgeryToken()
    <button type="submit">Save preferences</button>
</form>

import { csrfSync } from 'csrf-sync';
const { generateToken, csrfSynchronisedProtection } = csrfSync();

app.get('/csrf-token', (req, res) => {
  res.set('Cache-Control', 'no-store');
  res.json({ token: generateToken(req) });
});
app.post('/preferences', csrfSynchronisedProtection, (req, res) => {
  // Validate fields and authorize the update here.
  res.sendStatus(204);
});

class ApplicationController < ActionController::Base
  protect_from_forgery with: :exception
end

Regression checks¶

In an isolated application, a valid token from the current session should pass. Missing, malformed and another session's tokens should fail before any state change. Assert GET does not mutate data. Verify login/session rotation, expired sessions and cached-form behavior. Test actual browser requests because cookie and SameSite behavior cannot be established by a server unit test alone.

References¶

• OWASP CSRF prevention
• Django CSRF
• Spring Security CSRF
• ASP.NET Core antiforgery
• csrf-sync documentation
• Related: CORS and HTTP method semantics