50% off your first month.Start now →
Muster.
← Checklists

checklist

Fix an over-open CORS policy

A wildcard CORS policy is not always exploitable, but origin reflection with credentials is. How to tell the difference, fix it and prove it locally.

Rules: `http/cors-wildcard-with-credentials` (high), `http/cors-wildcard` (low)

What muster-check saw

``` HIGH CORS allows any origin and sends credentials src/api.ts:1 "Access-Control-Allow-Origin", "*" ```

Accuracy note

A literal `*` plus `Allow-Credentials: true` is rejected by browsers, so by itself it is a broken config, not a working attack. It is dangerous when the code mirrors the request `Origin` header back (the usual "fix" for that browser error). Fix both.

Fix

```ts const ALLOWED = new Set(["https://app.example.com"]); const origin = req.headers.origin; if (origin && ALLOWED.has(origin)) { res.setHeader("Access-Control-Allow-Origin", origin); res.setHeader("Access-Control-Allow-Credentials", "true"); res.setHeader("Vary", "Origin"); } ``` A plain `*` with no credentials is fine for a truly public, no-auth endpoint (low).

Prove it's fixed

```sh curl -si -H "Origin: https://evil.test" http://localhost:3000/api/me | grep -i access-control ``` Expect no `Access-Control-Allow-Origin` for the untrusted origin, and the allowed one echoed for your real origin. Local server only.

Run this checklist automatically, on every deploy.

Muster proves each finding with the exact request that worked and the fix that closes it. First findings in about 10 minutes, free.

Start free →