Scoring Cross-Site Scripting Consistently

Cross-site scripting has remained in the OWASP Top Ten for the entire history of that list, and it is among the most frequently reported classes of finding in bug bounty programmes. The difficulty is rarely detection — it is agreeing on how serious any particular instance is. A reflected payload on an unauthenticated marketing page and a stored payload in an administrative dashboard are the same class of bug with wildly different consequences, and an ad-hoc high, medium or low rating fails to capture that.

The Common Vulnerability Scoring System exists to make the judgement reproducible. It decomposes a finding into eight base metrics and combines them arithmetically, so two assessors working from the same facts arrive at the same number. This calculator implements the version 3.1 specification directly, including the roundUp function and the separate impact formula that applies when scope changes, and prints the vector string so the result can be pasted into an advisory or ticket.

Why Scope Changes and Why It Matters

Scope is the metric most often set incorrectly. It changes when a vulnerability in one security authority allows impact on resources governed by another. Cross-site scripting is the specification's own canonical example: the defect lies in the web application, but the injected code runs inside the victim's browser under the same-origin policy — a different authority entirely. That is why nearly every published XSS advisory carries S:C.

The consequence is arithmetic as well as conceptual. Changed scope substitutes a different impact formula, raises the privileges-required coefficients, and multiplies the combined result by 1.08. A stored XSS requiring low privileges with low confidentiality and integrity impact scores 5.4 under changed scope against 4.6 unchanged. Self-XSS is the common exception: because the victim must paste the payload into their own console, most programmes treat it as informational and score it with unchanged scope, if they accept it at all.

Base Score Versus Residual Risk

A frequent source of argument is whether defensive controls should lower the score. Under the specification they should not: the base score describes intrinsic properties of the vulnerability that are constant across every deployment, which is what makes scores comparable between organisations. A Content Security Policy, HttpOnly cookies and a web application firewall are properties of your environment, not of the bug.

That does not make them irrelevant to prioritisation, which is why this calculator reports them separately. The residual score applies the mitigating effect of your actual controls and the share of users exposed, producing a number suited to ordering a remediation backlog rather than to publishing in an advisory. A strict nonce-based CSP blocks the majority of injection payloads and meaningfully reduces residual risk; a policy containing unsafe-inline provides almost nothing. HttpOnly cookies prevent the simplest session-theft payload but leave an attacker free to act as the victim within the page, which is why the reduction credited here is small.

From Score to Remediation

The score should drive a timeline, not end the conversation. Findings above nine warrant immediate action, seven and above within a week, four and above within a month, and anything lower can usually be tracked in the normal backlog. Professional Mode adds environmental metrics so the rating reflects what the affected asset actually holds — the same technical flaw deserves a different priority on a public brochure site than on a portal holding medical records.

The fix itself is well understood. Context-aware output encoding is the primary control: data destined for an HTML body, an attribute, a JavaScript block, a stylesheet or a URL each require different escaping, and the framework's built-in mechanism should do it rather than a hand-written filter. Modern frameworks escape by default, so most surviving XSS in React or Angular codebases traces back to an explicit bypass such as dangerouslySetInnerHTML. Sanitise rich text with a maintained library like DOMPurify, validate input against an allowlist where the format permits, and deploy a strict CSP as the layer that catches what the other measures miss.