CORS, correctly

The Same-Origin Policy blocks a page on https://evil.docs.example.com from
reading responses from https://api.docs.example.com. CORS is how your API
selectively relaxes that — so it is a control you must configure deliberately,
not loosen to make an error go away.

The cardinal sins

Access-Control-Allow-Origin: * on an authenticated API. Any site can call
it. Browsers forbid * together with credentials — but the deeper problem is
trusting every origin at all.
Reflecting the Origin header unchecked. Echoing back whatever Origin
the request carried is effectively *, but worse: it works with credentials.
Access-Control-Allow-Credentials: true with a permissive origin. This
exposes cookie-authenticated endpoints cross-site.

The right way: explicit allow-list

# Only known, trusted front-end origins are allowed. The server checks the
# request Origin against an allow-list and reflects it ONLY on a match.
Access-Control-Allow-Origin: https://app.docs.example.com
Vary: Origin
Access-Control-Allow-Methods: GET, POST, PUT, PATCH, DELETE
Access-Control-Allow-Headers: Authorization, Content-Type
Access-Control-Allow-Credentials: true
Access-Control-Max-Age: 600

Rules:

Maintain an allow-list of exact origins (scheme + host + port). Reflect the
request's Origin only if it is on the list; otherwise send no CORS headers.
Always add Vary: Origin so caches don't serve one origin's CORS response to
another.
Scope Allow-Methods and Allow-Headers to what you actually use.
Use credentials only when you truly need cookie/session auth cross-origin; pair
it strictly with a single allow-listed origin.
Remember CORS is browser-enforced. It is not authentication — it does not
protect against non-browser clients. You still need real authn/authz.

The bundled ../src/node/cors.js middleware and
../config/cors-policy.example.yaml
implement exactly this allow-list pattern.

Included with API Security Framework

Ready for the complete API Security Framework?