What is Cross-Site Request Forgery (CSRF)?

Cross-Site Request Forgery (CSRF or XSRF) causes an authenticated user's browser to send an unwanted action to another website. Because browsers often attach cookies automatically, the target application may mistake the manipulated request for an intentional action by the victim.

How does CSRF work?

An attacker places a crafted form, image or script on another page. When the victim visits it, the browser sends a request to the vulnerable application. If the victim is signed in and the session is identified by cookies, the request carries that valid session. The application verifies who the user is, but not whether the user intended this particular action.

What conditions enable an attack?

• A relevant action exists, such as changing an email address, password, permission or payee.
• The application relies on automatically transmitted credentials such as session cookies.
• The attacker can predict or specify all necessary request parameters.
• No effective control verifies that the request comes from the intended application context.

Classic CSRF is usually not directly possible with bearer tokens that JavaScript deliberately puts into an Authorization header. If tokens are stored in cookies or alternative cookie-based endpoints exist, the actual behavior still needs testing.

What impact is possible?

Impact follows the abused function and the victim's privileges. Attackers may change profiles, create orders, generate API keys or modify administrative settings. CSRF normally cannot read the target response. Combined with cross-site scripting, CORS flaws or information disclosure, however, this boundary may disappear.

How is CSRF prevented?

Built-in framework protections are usually the best foundation. SameSite is an important additional control, but should not automatically be treated as the only defense.

Code example: CSRF protection in Laravel

Vulnerable: State change through GET and a form without a token.

// Unsafe route
Route::get('/account/delete', [AccountController::class, 'destroy']);

<form method="POST" action="/email/change">
    <input name="email">
</form>

Safe foundation:

Route::delete('/account', [AccountController::class, 'destroy'])
    ->middleware('auth');

<form method="POST" action="/account">
    @csrf
    @method('DELETE')
    <button type="submit">Delete account</button>
</form>

Laravel validates the token in its web middleware. Final account deletion should additionally require password or MFA confirmation.

Which protection failures are common?

A token fails if it is optional, predictable, not tied to the session or can be planted through another subdomain. Some applications check only POST while accepting the same action through GET or another method. Substring matching in Referer checks can be bypassed with similarly named domains. Login CSRF also matters: a victim is silently logged into an attacker-controlled account and later stores confidential information there.

How is CSRF tested?

Testers inventory state-changing requests and examine tokens, cookie attributes, method overrides and origin validation. They then build a minimal cross-origin proof on a separate test page. Coverage includes account changes, administrative functions, uploads, OAuth connections and API endpoints. A successful test modifies approved test data only.