CORS wildcard origins and request security
CORS controls which websites are allowed to call your API from a browser. If your server returns Access-Control-Allow-Origin: *, any site on the internet can send authenticated requests to your endpoints. That is almost never what you actually want.
#What goes wrong
When a route works locally but fails in production with a CORS error, the fastest fix is to set the allow-origin to a wildcard. AI tools suggest this constantly. The error goes away, the feature ships, and the security hole stays.
#Why it matters
A malicious site can make a user's browser send authenticated requests to your API just by them visiting the wrong page. With a wildcard origin, the attacker's site can read the responses too. That means session-bound endpoints, payment routes, and personal data are all reachable from any other website while your user is logged in.
#How Heimdall checks for this
Heimdall reads your Next.js config, Vercel config, middleware, and each API route handler. It searches for wildcard patterns in Access-Control-Allow-Origin headers and in cors() middleware calls. Any match on a route that handles auth, user data, or writes is flagged as critical. Wildcards on truly public read-only feeds get a softer warning.
#How to fix it
Replace the wildcard with an explicit allowlist of origins your app actually uses. Read those from an environment variable like ALLOWED_ORIGINS so the list does not have to be hardcoded per environment. For Next.js, you can do this in middleware.ts or in the headers() function inside next.config.ts.
Frequently asked questions
Is a wildcard ever safe?
Does setting credentials: true with a wildcard work?
What if my app needs to accept requests from many subdomains?
Run this check on your own repo
Heimdall scans your GitHub repo for this and 16 other issues in under a minute.