ShipGuardScan a site

CORS Wildcards and Origin Reflection: Fix Guide

Updated 2026-10-17

AI assistants often "fix" CORS errors with cors() defaults or by echoing the request Origin. That makes the error disappear — and lets any website read your API responses from your users' browsers.

Know the cases

  • * on public, unauthenticated data: acceptable
  • * on authenticated APIs using bearer tokens in JS: risky; restrict it
  • Reflected Origin + Access-Control-Allow-Credentials: true: serious — any site can make cookie-authenticated requests and read results

Allowlist

const ALLOWED = new Set(["https://your-app.com", "https://www.your-app.com"]);
export function corsHeaders(origin: string | null) {
  if (!origin || !ALLOWED.has(origin)) return {};
  return { "Access-Control-Allow-Origin": origin, "Access-Control-Allow-Credentials": "true", Vary: "Origin" };
}

Checklist

  • No reflected arbitrary origins
  • Credentials only for allowlisted origins
  • Vary: Origin set
  • Public endpoints separated from private ones

Copy-paste fix prompt

Replace my CORS configuration with an explicit allowlist of my frontend origins. Only send Access-Control-Allow-Credentials for allowlisted origins, add Vary: Origin, and keep `*` only on endpoints that serve public, unauthenticated data.

FAQ

Why does the browser reject `*` with credentials?

Browsers block that combination, which is why misconfigured servers reflect the Origin instead — and that reflection is the dangerous part.

Does CORS protect against server-to-server requests?

No. CORS is a browser control; servers must still authenticate every request.

Check your deployed app in ~25 seconds

Free passive scan: leaked keys, Supabase exposure, public config files and headers.

Run a free scan

Related