Fix guide · critical · cors_origin_reflected_with_credentials

Server reflects arbitrary Origin AND sets Allow-Credentials: true

What this rule means

vibecheck sent a request with Origin: https://attacker.example. Your server echoed it back in Access-Control-Allow-Origin AND set Access-Control-Allow-Credentials: true. Any malicious site can now make authenticated requests to your API as a logged-in victim and read the responses.

Why it matters

This is the lethal CORS bug. Allow-Credentials: true tells the browser to include cookies/auth headers in cross-origin requests; reflecting the Origin tells it to allow the request from any site. Combined, an attacker's page can:

  1. Make a logged-in user navigate to attacker.example.
  2. attacker.example issues a fetch('https://your-app.com/api/me', { credentials: 'include' }).
  3. The browser sends the user's session cookies.
  4. Your server validates the session, returns the user's data.
  5. Your server's CORS headers say 'attacker.example may read this response.'
  6. attacker.example reads the response and exfiltrates everything.

This is functionally equivalent to having no auth boundary on your API for cross-origin reads. Worse, it bypasses CSRF protections — those rely on the browser blocking cross-origin reads.

How to fix it

Treat as a critical incident.

  1. Stop reflecting the Origin. Replace the cors middleware with an explicit allowlist (see cors_origin_reflected for the exact code). Deploy immediately.
  1. Audit logs for cross-origin authenticated reads during the exposure window. Look for requests with an Origin header that doesn't match your real domains, paired with valid session cookies. Any such request was a potential exfiltration.
  1. Force re-auth for sensitive accounts. If you can identify users whose sessions might have been read cross-origin (active sessions during the exposure window with cross-origin requests in logs), invalidate those sessions and force re-login.
  1. Consider session rotation. A more aggressive response: rotate the JWT signing secret or session-cookie HMAC key. Logs out everyone but invalidates any stolen session token attackers might still be holding.

After fixing, verify:

curl -i -H "Origin: https://attacker.example" \
     -H "Cookie: your-session-cookie-name=value" \
     https://your-app.com/api/me
# Response should NOT include "Access-Control-Allow-Origin: https://attacker.example".
# It should include your allowlisted origin OR no ACAO header at all.

Full guide: /blog/cors-misconfig-vibe-coded.

Did vibecheck flag this on your app?

If you reached this page from a vibecheck inspection report, the redacted match in your scan output is the exact string we found in your bundle. After applying the fix above, run the inspection again — the finding should clear.

Run another inspection

Related fix guides