Skip to content
BuildThenTestedSee packages
HighDeploy and config

CORS open to any origin with credentials

Any website a signed-in user visits can call your API with that user's session and read the response, so their data leaves for a site you never approved. How code reaches production and how the server is configured. Check it yourself with the steps below; our test adds what a script and a second account can find.

What it looks like

// middleware.ts
const origin = req.headers.get('origin') ?? '*';
res.headers.set('Access-Control-Allow-Origin', origin);
res.headers.set('Access-Control-Allow-Credentials', 'true');
res.headers.set('Access-Control-Allow-Methods', '*');
The API echoes back whichever origin asked and allows cookies to travel with the request: a wildcard in effect, even though the literal `*` is avoided.

What happens

Any website a signed-in user visits can call your API with that user's session and read the response, so their data leaves for a site you never approved.

Where it shows up

Descriptive, not a verdict: builders and stacks whose defaults make this reachable, or that a public incident names. Each hub states the tool's own security features.

Seen in public

Tenzai had five coding agents build the same applications from identical prompts in December 2025 and found 69 vulnerabilities across 15 applications; none of the 15 apps had CSRF protection or security headers.

  • 69 Vulnerabilities found
  • 15 Applications tested
  • 5 Coding agents tested
  • 5 of 5 Agents that introduced SSRF
  • 0 of 15 Apps with CSRF protection
  • 0 of 5 Agents that set security headers
  • December 2025 Testing period

Jan 2026 · Tenzai · all sources

Check it yourself

Uses your builder's dashboard and your browser. No tools to install.

  1. Sign in to the live app, open browser devtools, go to the Network tab and click any request to your API.
  2. Read the response headers Access-Control-Allow-Origin and Access-Control-Allow-Credentials.
  3. Open an unrelated website in another tab, open its devtools console, and run fetch('https://your-app/api/some-route', { credentials: 'include' }).then(r => r.text()).then(console.log).
  4. Bad result: Allow-Origin equals the requesting site's origin (or *) while Allow-Credentials is true, and the fetch from the other site prints your data instead of a CORS error.

What we check

We send requests with a range of foreign origins, including lookalike domains and the null origin, and check whether the API reflects them alongside credentials. We then confirm whether session cookies would actually be sent given their SameSite setting, and report per route.

Fix direction

Keep an explicit allow list of your own origins and return exactly one matching origin per response; never reflect the request origin unchecked. If the API only serves your own front end on the same domain, remove the CORS headers entirely. Set session cookies with a SameSite attribute so a foreign site cannot ride the session.

Mechanism documented in: Cross-Origin Resource Sharing (CORS) (verified 2026-09-21).

Covered by

Pre-launch check ($490, 48 hours) and Full audit ($1,900, 5 business days)

Both include a re-check after your fixes.

Compare packages

Related patterns

  • Missing security headersDeploy and config

    Without these headers a browser will happily load the app inside someone else's page, over plain HTTP, or with injected scripts, which turns an otherwise small bug into a working attack.

    Medium
  • Authorization enforced only in the browserLogin and permissions

    Anyone who calls the API directly, or edits the page in developer tools, gets the data and actions the screen was hiding.

    Critical
  • Tokens trusted without server verificationLogin and permissions

    Anyone can write their own token naming another user, or an admin, and the server will act as that person.

    Critical
  • Sessions that survive logout and password changesLogin and permissions

    Someone who once had a user's token, on a shared computer or through a leak, keeps access after the user logs out or changes their password.

    High

Questions

what does access-control-allow-origin * mean

CORS (cross-origin resource sharing) is the browser rule that decides which other websites may read responses from your API. Access-Control-Allow-Origin: * tells browsers any site may read them. MDN documents that browsers refuse the * value when credentials such as cookies are included. Code that needs both often switches to echoing the caller's origin, which is the same openness in a form browsers accept.

is cors wildcard with credentials a security risk

The literal combination is blocked by browsers, so on its own it breaks the app rather than exposing data. The working variant, reflecting whatever origin asked while allowing credentials, lets any site a logged-in user visits read that user's API responses. Tenzai's comparison of coding agents found that none of the agents set security headers on the apps they built, and CORS headers fall into that same family of response settings left to you (Tenzai, 2026). Check your API's response headers in devtools today.

how to fix cors in next.js api routes

Decide which origins genuinely need to call the API, usually just your own front end, and compare the incoming Origin header against that list in your middleware or route handler. Return the matched origin, not the wildcard and not the raw request value. If the front end and API share a domain, you can drop the CORS headers and the problem with them.

Back to the catalogue, or run the self-check for your stack.