Cross-Site Scripting (XSS) Risk Calculator
Score reflected, stored and DOM XSS risk from output encoding, sanitiser quality, CSP strength and the privilege of the likely victim.
About Cross-Site Scripting (XSS) Risk Calculator
Stored XSS scores highest on likelihood because the payload fires without the attacker needing to lure anyone, and DOM XSS sits above reflected because it often bypasses server-side filtering entirely. Impact is driven by who executes the payload: an administrator session with a readable cookie is a full application takeover. XSS severity is decided by the second line of defence, not the injection itself — the same flaw is a Low with a nonce CSP and HttpOnly cookies, and a Critical without them.
Formula
Cross-Site Scripting (XSS) Risk
Likelihood = mean(XSS class, output encoding, sanitiser quality, CSP strength); impact = mean(cookie flags, reachable audience, victim privilege) on the OWASP 0–9 scale.
- xssType
- 5 reflected, 7 DOM, 9 stored
- csp
- 1 nonce-based … 9 no policy
- privilege
- Privilege the stolen session carries
Worked example
With the default values below, Cross-Site Scripting (XSS) Risk Calculator returns Overall Risk Severity of Critical. Change any input above and every figure here is recalculated in your browser.
Inputs used
- XSS classone of Reflected — 5, DOM-based — 7, Stored or persistent — 9
- Stored or persistent — 9
- Context-aware output encodingone of Framework auto-escaping everywhere — 1, Encoded in most contexts — 4, Ad-hoc HTML escaping only — 6, None — 9
- Ad-hoc HTML escaping only — 6
- HTML sanitiser on rich-text inputone of Vetted allow-list sanitiser such as DOMPurify — 1, Home-grown deny-list filter — 7, None — 9
- Home-grown deny-list filter — 7
- Content Security Policyone of Nonce or hash based with strict-dynamic — 1, Host allow-list without unsafe-inline — 3, Allow-list with unsafe-inline — 6, No CSP — 9
- Allow-list with unsafe-inline — 6
- Session cookie flagsone of HttpOnly with SameSite=Strict — 2, HttpOnly with SameSite=Lax — 4, HttpOnly only — 6, Neither flag set — 9
- HttpOnly only — 6
- Audience the payload can reachone of A single user session — 4, One team or tenant — 6, All authenticated users — 7, Anonymous visitors and administrators — 9
- Anonymous visitors and administrators — 9
- Privilege of the likely victimone of Read-only user — 3, Standard user — 5, Privileged operator — 7, Administrator — 9
- Privileged operator — 7
Results
- Overall Risk Severity
- Critical
- Likelihood Score
- 7.00 / 9
- Impact Score
- 7.33 / 9
- Risk Score
- 5.70 / 9
- CSP as a Second Line of Defence
- Weak — unsafe-inline defeats the policy
- Highest-Value Fix
- Encode output for its context: HTML, attribute, JavaScript and URL
Step by step
- 1Values used
- 2Cross-Site Scripting (XSS) Risk
- 3Overall Risk Severity= Critical
- 4Likelihood Score= 7.00 / 9
- 5Impact Score= 7.33 / 9
- 6Risk Score= 5.70 / 9
- 7CSP as a Second Line of Defence= Weak — unsafe-inline defeats the policy
- 8Highest-Value Fix= Encode output for its context: HTML, attribute, JavaScript and URL
Assumptions and limits
- The result is derived only from the 7 inputs listed above. Anything not among them is not part of the calculation.
- In particular, this calculator does not take inflation, tax 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 Cross-Site Scripting (XSS) Risk calculated?
Likelihood = mean(XSS class, output encoding, sanitiser quality, CSP strength); impact = mean(cookie flags, reachable audience, victim privilege) on the OWASP 0–9 scale. Stored XSS scores highest on likelihood because the payload fires without the attacker needing to lure anyone, and DOM XSS sits above reflected because it often bypasses server-side filtering entirely. Impact is driven by who executes the payload: an administrator session with a readable cookie is a full application takeover.
Why does Cross-Site Scripting (XSS) Risk matter?
XSS severity is decided by the second line of defence, not the injection itself — the same flaw is a Low with a nonce CSP and HttpOnly cookies, and a Critical without them.
What values do I need to enter?
This calculator takes 7 inputs: XSS class, Context-aware output encoding, HTML sanitiser on rich-text input, Content Security Policy, Session cookie flags, Audience the payload can reach, Privilege of the likely victim. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.
Why does CSP appear under likelihood rather than impact?
Because a strict CSP stops the injected script from running at all, which changes whether the exploit succeeds — that is a likelihood question. Cookie flags, by contrast, limit what a successful payload can steal, so they belong to impact.