CSRF Risk Calculator

Rate cross-site request forgery exposure from token design, SameSite cookies, request shape and the value of the forged action.

About CSRF Risk Calculator

SameSite=Lax already blocks cross-site form POSTs in current browsers, so the residual likelihood depends on whether state changes are reachable by top-level GET and whether any user still runs a browser without the default. Impact is the worth of one forged action multiplied out across the exposed user base. CSRF is the cheapest attack to launch — a hidden form on any page the victim visits — and the cheapest to fix, so a Medium or higher here is almost always a missing one-line middleware.

Formula

CSRF Risk

Likelihood = mean(token strength, SameSite attribute, request shape, step-up authentication); impact = value of the forged action plus a scale uplift for the exposed user base.

token: 1 synchroniser token … 9 none
sameSite: 1 Strict, 4 Lax, 6 unset, 7 None
scaleBoost: 0–2 uplift for the number of exposed users

Worked example

With the default values below, CSRF Risk Calculator returns Overall Risk Severity of Critical. Change any input above and every figure here is recalculated in your browser.

Inputs used

Anti-CSRF tokenone of Per-session synchroniser token verified server-side — 1, Double-submit cookie token — 4, Origin or Referer check only — 6, None — 9: None — 9
SameSite attribute on the session cookieone of Strict — 1, Lax — 4, Not set, relying on browser defaults — 6, None with Secure — 7: Not set, relying on browser defaults — 6
Shape of the state-changing requestone of JSON body with a custom header, preflighted — 2, Form-encoded POST — 6, State change accepted on GET — 9: Form-encoded POST — 6
Step-up authentication on sensitive actionsone of Re-authentication or MFA per sensitive action — 1, Re-authentication for a subset of actions — 5, None — 9: None — 9
Value of the forged actionone of Preference change — 3, Data modification — 5, Funds transfer or role change — 7, Email or password change, i.e. account takeover — 9: Email or password change, i.e. account takeover — 9
Authenticated users exposedaccepts 1–100,000,000 users: 50,000 users

Results

Overall Risk Severity: Critical
Likelihood Score: 7.50 / 9
Impact Score: 9.00 / 9
Risk Score: 7.50 / 9
Browser-Level Defence: No usable browser-level defence
Highest-Value Fix: Add a per-session synchroniser token verified on every state change

Step by step

1Values used
2CSRF Risk
3Overall Risk Severity= Critical
4Likelihood Score= 7.50 / 9
5Impact Score= 9.00 / 9
6Risk Score= 7.50 / 9
7Browser-Level Defence= No usable browser-level defence
8Highest-Value Fix= Add a per-session synchroniser token verified on every state change

Assumptions and limits

The result is derived only from the 6 inputs listed above. Anything not among them is not part of the calculation.
In particular, this calculator does not take inflation, tax, fees or charges or compounding frequency into account.
Figures are rounded for display to 2 decimal places, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.

How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.

Frequently Asked Questions

How is CSRF Risk calculated?

Likelihood = mean(token strength, SameSite attribute, request shape, step-up authentication); impact = value of the forged action plus a scale uplift for the exposed user base. SameSite=Lax already blocks cross-site form POSTs in current browsers, so the residual likelihood depends on whether state changes are reachable by top-level GET and whether any user still runs a browser without the default. Impact is the worth of one forged action multiplied out across the exposed user base.

Why does CSRF Risk matter?

CSRF is the cheapest attack to launch — a hidden form on any page the victim visits — and the cheapest to fix, so a Medium or higher here is almost always a missing one-line middleware.

What values do I need to enter?

This calculator takes 6 inputs: Anti-CSRF token, SameSite attribute on the session cookie, Shape of the state-changing request, Step-up authentication on sensitive actions, Value of the forged action, Authenticated users exposed. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.

Is SameSite=Lax enough on its own?

Not for defence in depth. Lax blocks cross-site POST but still sends the cookie on top-level GET navigations, so any state change reachable by GET remains forgeable, and cookies without an explicit attribute behave inconsistently across browsers and API clients. Keep a token as well.