CORS Policy Calculator

Test a CORS configuration for the combinations that leak data cross-origin, and score the residual risk against your data sensitivity.

About CORS Policy Calculator

The dangerous combination is a reflected or loosely matched origin together with Allow-Credentials: true, because that lets any page the victim visits read authenticated responses from your API. A wildcard origin scores lower than reflection since browsers refuse to combine * with credentials at all. A permissive CORS policy is a same-origin bypass you deployed yourself — it turns every authenticated GET endpoint into a cross-origin data feed with no exploit required.

Formula

CORS Policy

Configuration risk = mean(origin policy, credentials, methods, headers, exposed headers) on the OWASP 0–9 scale, plus 2 when an opaque origin is accepted; impact = data sensitivity.

originPolicy: 1 fixed origin … 9 regex or suffix match
credentials: 1 not sent … 9 true with a reflected origin

Worked example

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

Inputs used

Access-Control-Allow-Originone of A single fixed origin — 1, Server-side allow-list, exact match — 2, Wildcard * — 6, Reflects the request Origin — 8, Regex or suffix match on Origin — 9: Reflects the request Origin — 8
Access-Control-Allow-Credentialsone of Not sent — 1, true with an exact allow-list — 5, true with a reflected origin — 9: true with a reflected origin — 9
Allowed methodsone of GET and HEAD only — 2, GET and POST — 4, All state-changing methods — 7, Wildcard * — 9: All state-changing methods — 7
Allowed request headersone of Content-Type only — 2, Explicit list including Authorization — 5, Wildcard * — 9: Explicit list including Authorization — 5
Exposed response headersone of None — 1, An explicit non-sensitive list — 4, Wildcard, or includes tokens — 9: An explicit non-sensitive list — 4
Opaque origin (sandboxed iframe / local file) is accepted: No
Sensitivity of the data behind the APIone of Public — 2, Internal — 5, Customer PII — 7, Credentials or financial records — 9: Customer PII — 7
Access-Control-Max-Ageaccepts 0–86,400 seconds: 600 seconds

Results

Overall Risk Severity: Critical
Configuration Risk: 6.60 / 9
Impact Score: 7.00 / 9
Credentialed Cross-Origin Read: Possible — any allowed origin can read authenticated responses
Preflight Cache: Reasonable — preflights are cached, so latency stays low
Highest-Value Fix: Replace Origin reflection with an exact server-side allow-list

Step by step

1Values used
2CORS Policy
3Overall Risk Severity= Critical
4Configuration Risk= 6.60 / 9
5Impact Score= 7.00 / 9
6Credentialed Cross-Origin Read= Possible — any allowed origin can read authenticated responses
7Preflight Cache= Reasonable — preflights are cached, so latency stays low
8Highest-Value Fix= Replace Origin reflection with an exact server-side allow-list

Assumptions and limits

The result is derived only from the 8 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 CORS Policy calculated?

Configuration risk = mean(origin policy, credentials, methods, headers, exposed headers) on the OWASP 0–9 scale, plus 2 when an opaque origin is accepted; impact = data sensitivity. The dangerous combination is a reflected or loosely matched origin together with Allow-Credentials: true, because that lets any page the victim visits read authenticated responses from your API. A wildcard origin scores lower than reflection since browsers refuse to combine * with credentials at all.

Why does CORS Policy matter?

A permissive CORS policy is a same-origin bypass you deployed yourself — it turns every authenticated GET endpoint into a cross-origin data feed with no exploit required.

What values do I need to enter?

This calculator takes 8 inputs: Access-Control-Allow-Origin, Access-Control-Allow-Credentials, Allowed methods, Allowed request headers, Exposed response headers, Opaque origin (sandboxed iframe / local file) is accepted, Sensitivity of the data behind the API, Access-Control-Max-Age. 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 is Origin reflection worse than a wildcard?

Because reflection works with credentials and a wildcard does not. Browsers reject Access-Control-Allow-Origin: * whenever Allow-Credentials is true, so a wildcard leaks only unauthenticated data. Reflecting whatever Origin arrives satisfies the browser check for every attacker origin at once.