Cors Configurator

Fix the specific, maddening case where a request works from curl or Postman but the browser blocks it with a CORS error. CORS is enforced by the browser, not the server — so the failure is always that the server isn't returning the response headers the browser requires for a cross-origin request. This skill reads the exact error, determines what the browser is asking for, and sets the minimal correct headers on the server, without disabling the protection or opening the API to every origin.

[!NOTE] CORS is a browser policy, not a server-side security control. Loosening it doesn't make your API safer or more dangerous to non-browser clients — but a wildcard-with-credentials or reflect-any-origin "fix" does expose authenticated users to malicious sites. Scope it to the origins you actually serve.

When to use this skill

• A browser fetch/XHR fails with "No 'Access-Control-Allow-Origin' header" or "…does not pass access control check", but the same endpoint works from curl.
• A request started failing after you added Authorization headers, custom headers, cookies, or switched to PUT/DELETE (it became preflighted).
• The preflight OPTIONS request returns 404/405 or the wrong headers.
• You set Access-Control-Allow-Origin: * and it broke once credentials were involved.

Instructions

1. Read the exact error and the request. Get the precise browser console message and the request's origin, method, and headers. The error text names what's missing (origin not allowed, method not allowed, header not allowed, credentials mismatch).
2. Classify simple vs. preflighted. A simple request (GET/HEAD/POST with only safelisted headers and content types) needs only the right headers on the actual response. A preflighted request (custom headers, Authorization, JSON body via non-safelisted content type, or PUT/PATCH/DELETE) first sends an OPTIONS preflight — the server must answer that too.
3. Find where responses are produced. Locate the CORS middleware or the place response headers are set (framework CORS package, a reverse proxy, or manual header code). Confirm whether a proxy in front is adding or stripping CORS headers — duplicated or conflicting headers are a common cause.
4. Set the origin correctly. For requests without credentials you may use Access-Control-Allow-Origin: *. For requests with credentials, you must echo a specific allowlisted origin (never *), add Access-Control-Allow-Credentials: true, and add Vary: Origin so caching stays correct. Check the incoming Origin against an explicit allowlist; don't reflect arbitrary origins.
5. Answer the preflight. Ensure OPTIONS on the route returns 204/200 with Access-Control-Allow-Methods (the methods you allow), Access-Control-Allow-Headers (echo or list the requested headers, e.g. Authorization, Content-Type), and Access-Control-Max-Age to cache the preflight and cut round-trips. Make sure the OPTIONS route isn't swallowed by auth middleware or a 404.
6. Prefer the framework's CORS support. Use the maintained CORS middleware (e.g. cors for Express, CORSMiddleware for FastAPI/Starlette, the framework's config) with an explicit origin allowlist rather than hand-writing headers on every route.
7. Verify with a real preflight. Reproduce the preflight from the shell and confirm the headers, then re-test in the browser:

   curl -i -X OPTIONS https://api.example.com/things \
     -H "Origin: https://app.example.com" \
     -H "Access-Control-Request-Method: PUT" \
     -H "Access-Control-Request-Headers: authorization,content-type"
   

   The response must include Access-Control-Allow-Origin: https://app.example.com (or * when credential-free), the allowed method, and the allowed headers.

Examples

An Express API called from https://app.example.com with a cookie session, currently sending Access-Control-Allow-Origin: * and failing once credentials were added:

import cors from "cors";

const allowedOrigins = ["https://app.example.com", "http://localhost:3000"];

app.use(
  cors({
    origin(origin, cb) {
      // allow same-origin/non-browser (no Origin) and allowlisted origins
      if (!origin || allowedOrigins.includes(origin)) return cb(null, true);
      return cb(new Error("Not allowed by CORS"));
    },
    credentials: true,                          // echoes a specific origin, not *
    methods: ["GET", "POST", "PUT", "DELETE"],
    allowedHeaders: ["Authorization", "Content-Type"],
    maxAge: 86400,
  })
);

Report the outcome: what the browser was actually rejecting (origin / method / header / credentials), the exact headers now returned, that the OPTIONS preflight succeeds, and the allowlist you scoped it to — plus a note that origins are an explicit list, not a reflect-all.