Group
  • Security

    Fix my CORS configuration

    Replaces wildcard CORS with an explicit origin allowlist and correct credential handling.

    • Improve quality
    • Debug & fix
    • Beginner
    • General

Free Prompt

Audit my app's CORS configuration. Find where Access-Control-Allow-Origin and related headers are set, whether that's framework middleware, manual headers, or hosting config. Apply these rules: allow only my actual frontend origins (explicit domains, including the local dev origin for development only); never use a wildcard * origin on endpoints that accept cookies or authorization headers; never reflect the request's Origin header back blindly (that defeats CORS entirely); only allow the methods and headers the API actually uses; and don't expose credentials (Access-Control-Allow-Credentials: true) to any origin that isn't explicitly trusted. Do not break the frontend's ability to call the API. If the frontend and API are on the same domain, tell me whether CORS headers are needed at all. Keep preflight (OPTIONS) handling working. Show me the config before and after. Give me verification: a curl request with an untrusted Origin header that gets no allow-origin header back, and one from my real origin that does.

What This Does / How This Helps

Replaces the wildcard or reflect-any-origin CORS setup with an explicit allowlist of the origins your frontend actually uses. CORS misconfiguration is a quiet one. With a wildcard or a reflected origin plus credentials, any site can make authenticated requests to your API from a victim's browser and read the responses. It's the classic "temporary" config (set to * to get things working) that ships to production and stays there. Verification is built in: requests from a fake origin should come back without access headers, and requests from your real domain should work unchanged.

Want to skip doing this by hand?

Fortivibe audits your app for all of the areas these prompts cover (and more).

See What We Check

Related Prompts