CORS Policy Risk Checker

Cross-Origin Resource Sharing, usually shortened to CORS, is the browser rule system that decides whether JavaScript from one origin may read a response from another origin. The central question is narrow but important: when a browser sends an Origin header, does the response name a trusted origin, allow every origin, or fail to name a readable origin at all?

CORS does not authenticate users, replace CSRF defenses, or stop direct server-to-server traffic. It controls browser read access. That distinction matters for APIs, partner dashboards, admin consoles, and single-page applications because a broad CORS response can let an unrelated website read data that the server was willing to return to the browser.

Risk rises when the response is readable by origins that were not meant to use it, when credentials are allowed with a loose origin rule, when state-changing methods are broadly available, or when sensitive headers become visible to browser JavaScript. A missing or weak CORS header can also be intentional for a route that should not be read cross-origin.

A useful CORS review therefore combines browser protocol rules with deployment intent. The same wildcard can be reasonable for a public static resource and unacceptable for a credentialed account API. The same exact origin can be correct when it matches a maintained allowlist and suspicious when it merely reflects whatever origin was sent in the request.

Technical Details:

The browser starts a CORS decision with the request origin and the response's access-control headers. Access-Control-Allow-Origin must be either one serialized origin, the wildcard *, or the special value null. When credentials are part of the request, a wildcard origin is not enough for the browser to expose the response to JavaScript.

Exact origins carry their own cache concern. If a server chooses an origin dynamically from an allowlist, shared caches need to know that the response can differ by request origin. Vary: Origin is the usual signal for that case. Without it, a cache may reuse a response whose readable origin was chosen for a different caller.

The checker uses rule-based findings instead of trying to prove exploitability. Each finding records a severity, the header evidence, and a recommendation. The numeric score is a capped sum of finding weights, so several medium or high findings can produce a Critical band even when only one finding would not.

The input parser is intentionally header-focused. Status lines are skipped, blank lines are ignored, and only name: value lines become header evidence. That keeps response bodies, request bodies, and unrelated terminal output out of the review.

Everyday Use & Decision Guide:

Start with the response that represents the route under review. For CORS bugs, that is often an OPTIONS preflight response and the actual response from the same route. Paste the headers into Response headers, name the route in Endpoint label, and enter the browser origin you tested in Observed request Origin.

Put the approved production origins in Approved origins, one per line. Exact origins are strongest. Patterns such as https://*.example.com are useful for review, but they should match real policy intent rather than become a substitute for knowing which applications are trusted.

• Leave Credentialed requests expected on for routes that use cookies, HTTP authentication, client certificates, or credentialed fetch/XHR.
• Leave Response may contain sensitive data on for account, admin, billing, personal, partner, or internal API responses.
• Use Normalize headers after pasting from DevTools, curl -i, or a proxy trace when repeated whitespace makes the sample hard to read.
• Keep Require Vary: Origin for specific ACAO on for reflected or per-origin responses behind a CDN, reverse proxy, or shared cache.
• Lower Preflight max-age review limit during incident cleanup so stale browser preflight results do not hide policy changes for too long.
• Keep Treat Private Network Access as sensitive on for admin panels, routers, device APIs, internal dashboards, and private address space.

The safest reading path is summary, then Header Snapshot, then Risk Register. The summary gives the total score, parsed header count, credential badge, origin badge, and approved-origin cue. Header Snapshot shows the normalized values that fed the review. Risk Register is where the actual decisions live because each row includes the signal, evidence, and recommendation.

Do not treat a Low score as approval. It means the pasted headers did not trigger the checked risk signals under the current settings. You still need to confirm the server-side allowlist, the route's data sensitivity, authentication, CSRF protection, and the response that real users receive.

Step-by-Step Guide:

Review one endpoint and one observed origin at a time so the score, register, and chart describe the same browser access decision.

1. Enter Endpoint label with the route or service name you want shown in the summary, such as partner-api /v1/account.
2. Enter Observed request Origin. Use the exact browser origin from the request, such as https://app.example.com, https://evil.example, or null.
3. Add trusted browser origins in Approved origins. If this field is empty, Input review warns that reflected or specific origins cannot be checked against an allowlist.
4. Paste raw response headers into Response headers. If Input review says lines were ignored, fix missing colons or remove non-header text before relying on the result.
5. Set Credentialed requests expected and Response may contain sensitive data to match the route. These switches change how wildcard, reflected, and null origins are judged.
6. Open Advanced when cache or private-network policy matters. Adjust Preflight max-age review limit, Require Vary: Origin for specific ACAO, and Treat Private Network Access as sensitive.
7. Read the summary. A line such as Critical - 100/100 means the combined finding weights reached the top band; Low - 0/100 means only the informational baseline row remained.
8. Open Risk Register and act on the highest severity rows first. Use the Evidence column to confirm the header value and the Recommendation column as the review note.
9. Open CORS Exposure Map to see which categories contributed score. A tall Credentials or Origin trust bar should send you back to ACAO, ACAC, and the approved origin list.

A clean handoff has no Critical or High findings, a Header Snapshot that matches the intended route, and approved origins that match the real application list rather than a convenient test origin.

Interpreting Results:

The most important output is the first actionable row in Risk Register. The total score helps triage, but a single row such as Wildcard origin with credentials, Unapproved origin reflected, or Sensitive headers exposed usually tells you what to fix before release review.

Be careful with absence. Missing Access-Control-Allow-Origin can be correct when a route should not be readable cross-origin. It becomes a review finding here because the route was submitted for CORS review and may have been expected to allow browser access.

The chart is a quick category view, not a replacement for header evidence. Use it to spot whether the problem is mainly origin trust, credentials, methods, cache behavior, exposed headers, or private network access, then make the change named in the Risk Register.

Worked Examples:

Approved credentialed API response

A route labeled partner-api /v1/account is tested from https://app.example.com, with approved origins set to https://app.example.com and https://admin.example.com. The response includes Access-Control-Allow-Origin: https://app.example.com, Access-Control-Allow-Credentials: true, Access-Control-Allow-Methods: GET, POST, OPTIONS, Access-Control-Max-Age: 600, and Vary: Origin. The summary reads Low - 0/100, Header Snapshot marks the origin as Approved, and Risk Register shows No baseline CORS risk signal.

Wildcard policy on a sensitive route

The risky sample uses Access-Control-Allow-Origin: *, Access-Control-Allow-Credentials: true, state-changing methods, authorization-related request headers, exposed authorization/session headers, Access-Control-Allow-Private-Network: true, and Access-Control-Max-Age: 86400. With credentialed requests and sensitive response enabled, the summary reaches Critical - 100/100. Risk Register includes Wildcard origin with credentials, State-changing methods broadly allowed, Sensitive request headers accepted broadly, Sensitive headers exposed, Risky preflight cache duration, and Private Network Access allowed broadly.

Unapproved origin reflection

An incident review tests Observed request Origin as https://staging.example.net while Approved origins lists only production app and admin origins. If the response returns Access-Control-Allow-Origin: https://staging.example.net with credentials enabled, the Risk Register flags Unapproved origin reflected. If Vary: Origin is also missing, the cache finding appears beside the origin trust finding because an origin-specific response may pass through shared caching.

Header paste cleanup

A copied terminal excerpt such as Access-Control-Allow-Origin https://app.example.com is not a valid name: value header line, so Input review reports an ignored line and Header Snapshot may show ACAO as missing. Add the colon, remove unrelated response-body text, use Normalize headers, and check Header Snapshot again before using the Risk Register in a handoff.

Responsible Use Note:

Response headers can expose internal service names, partner routes, private origins, auth patterns, cache settings, and security-control gaps. Paste the smallest useful header sample and remove unrelated tokens, IDs, or hostnames when the review does not need them.

The assessment runs in the browser session and does not need request or response bodies. Copied tables, downloaded JSON, chart images, and shareable URL state can still contain sensitive operational evidence, so handle those outputs under the same rules as the source headers.

FAQ:

Glossary:

Origin

The scheme, host, and port that identify where browser JavaScript is running, such as https://app.example.com.

ACAO

Short for Access-Control-Allow-Origin, the response header that names which origin may read the response.

ACAC

Short for Access-Control-Allow-Credentials, the response header that opts into exposing credentialed responses when other CORS rules pass.

Vary: Origin

A cache signal that tells shared caches the response can change based on the request Origin.

Preflight

An OPTIONS request browsers send before some cross-origin requests to ask which methods and headers are allowed.

Exposed headers

Response headers named by Access-Control-Expose-Headers so browser JavaScript may read them.

Private Network Access

A browser protection that adds preflight checks before less-private websites access more-private network resources.

References:

• Fetch Standard, CORS protocol and credentials, WHATWG.
• Cross-Origin Resource Sharing (CORS), MDN Web Docs.
• Access-Control-Allow-Origin header, MDN Web Docs, November 21, 2025.
• Private Network Access: introducing preflights, Chrome for Developers, July 7, 2022.