Cors Origin Guard

How everyone arrives at the hole

CORS is met as a console error, so it is debugged until the error stops. The fixes, in the order people reach for them:

1. Access-Control-Allow-Origin: * — works, until credentials are needed 2. reflect back whatever Origin was sent — works always 3. an allowlist — correct, and the only one that stays correct

Step 2 is the one that ships. It means a user visiting an attacker's page has **their own browser use their session against your API, and hand back the response.** There is no console error, because that is a correctly-functioning CORS configuration. It permits everyone.

The route there is worth naming: * plus credentials is rejected by every browser, but the message blames the origin — so people reflect the origin to "fix it" and arrive at an open API through what felt like debugging. This refuses that policy combination outright and says what the workaround costs.

Exact match only

Suffix and prefix checks are the classic bypass, and both read as reasonable:

• origin.endsWith("myapp.com") accepts https://evil-myapp.com
• origin.startsWith("https://myapp.com") accepts https://myapp.com.evil.invalid

Both are registrable by anyone. Scheme, host and port must match exactly, and null is refused — that is sandboxed iframes, some redirects and file:// pages, contexts you cannot identify or revoke.

Two details that only break behind a CDN

Vary: Origin is always set when the allowed origin varies. Without it a shared cache can serve a response carrying one origin's Allow-Origin header to a different origin — a poisoning bug that appears only behind a CDN and reads as an intermittent CORS failure.

A disallowed origin gets NO CORS headers at all, rather than headers that deny. Absent headers make the browser block the read; a mismatched Allow-Origin blocks it too while implying the endpoint considered and approved something.

Auditing the policy, not just the request

auditPolicy catches what no single request can: a * hiding in the origin list, a wildcard pattern (https://*.example.com — patterns are how evil.invalid gets in), a trailing slash (an Origin header never has one, so the entry is silently dead), and plaintext http in production.

What this does NOT do

No middleware for any framework, no header writing, no request handling — it returns the headers you should send and you send them.

CORS is not authorisation. It restricts what a browser will let one origin read. It does nothing about a direct request from curl, a server, or any non-browser client — those never send an Origin and are unaffected. If your API needs to be private, authenticate it; this stops other websites using a logged-in user's session, which is a different problem.

No CSRF protection. Related, commonly confused, different mechanism.

Verified

18 tests: exact matching, suffix and prefix bypasses refused, scheme and port treated as distinct origins, null refused, the wildcard-plus-credentials policy refused with its consequence named, wildcards allowed on uncredentialed endpoints, no headers for a disallowed origin, Vary: Origin always set, credentials only when requested, preflight methods/headers/max-age, a preflight asking for an unpermitted header refused, case-insensitive header matching, and five policy audit cases.

Not covered: nothing here runs against a real browser, so the behaviour is argued from the CORS specification rather than observed across browser versions.