highWeb Security

CORS Wildcard Misconfiguration Allows Unauthorized Cross-Origin Access

What Is This Vulnerability?

Cross-Origin Resource Sharing (CORS) controls which external domains can access your API. Setting the Access-Control-Allow-Origin header to a wildcard (*) or dynamically reflecting any origin without validation allows any website to make authenticated requests to your server, potentially leaking sensitive data.

Why It Happens

Developers often set permissive CORS policies during local development to avoid cross-origin errors and then forget to restrict them before deploying to production. Some teams also misconfigure CORS middleware by reflecting the request Origin header without checking it against an allowlist.

Example Code

Vulnerableserver.ts
import express from "express";
import cors from "cors";

const app = express();

// Allows ANY origin to access the API
app.use(cors({ origin: "*", credentials: true }));

app.get("/api/user/profile", (req, res) => {
  res.json({ email: req.user.email, balance: req.user.balance });
});
Fixedserver.ts
import express from "express";
import cors from "cors";

const allowedOrigins = [
  "https://myapp.com",
  "https://admin.myapp.com",
];

const app = express();

app.use(
  cors({
    origin(origin, callback) {
      if (!origin || allowedOrigins.includes(origin)) {
        callback(null, true);
      } else {
        callback(new Error("Blocked by CORS"));
      }
    },
    credentials: true,
  }),
);

app.get("/api/user/profile", (req, res) => {
  res.json({ email: req.user.email, balance: req.user.balance });
});

How Hackers Exploit It

An attacker hosts a malicious page that makes fetch requests to your API. Because the wildcard CORS policy returns permissive headers, the browser allows the attacker's script to read the response. The attacker can steal session tokens, personal data, or financial information from any logged-in user who visits the malicious page.

How to Fix It

Replace the wildcard origin with an explicit allowlist of trusted domains. Validate the incoming Origin header against this list before reflecting it. Never combine credentials: true with a wildcard origin. Use environment-specific CORS configurations so development and production have different policies.

Frequently Asked Questions

Is Access-Control-Allow-Origin: * always dangerous?
It is safe only for truly public resources that contain no user-specific data and require no authentication. For any endpoint that uses cookies, tokens, or returns private information, a wildcard origin creates a serious security risk.
Can CORS be exploited if my API does not use cookies?
Yes. If your API accepts Bearer tokens and the frontend stores them in localStorage, a malicious page can use JavaScript to read the token and replay it in requests to your API, bypassing CORS protections entirely.
How do I allow multiple origins securely?
Maintain an explicit allowlist of trusted origins. In your CORS middleware, check the incoming Origin header against this list and only reflect it back if it matches. This keeps your policy tight while supporting multiple frontends.

Related Security Topics

Insecure Cookie Flags Allow Session Hijacking and CSRF

Learn about insecure cookie flags allow session hijacking and csrf and how to fix it.

Open Redirect Vulnerability Enables Phishing and Token Theft

Learn about open redirect vulnerability enables phishing and token theft and how to fix it.

Clickjacking Vulnerability Due to Missing Frame Protection

Learn about clickjacking vulnerability due to missing frame protection and how to fix it.

Check Your Code for This Vulnerability

Run a free scan to check if your site is affected by cors wildcard misconfiguration allows unauthorized cross-origin access.