CORS misconfiguration: how to test your API

By Shinobi Tech, the team behind AppLeakWatch. Updated .

CORS decides which other websites may read your API's responses in a browser. It's dangerous when your API echoes any origin and also allows credentials, because another site may be able to read a signed-in user's data.

Why this happens

When a browser shows a CORS error, the quickest way to silence it is to allow everything. AI tools often do exactly that, and the error disappears while the risk stays.

How to check

  1. Send a made-up origin to your own API:
    curl -i -H "Origin: https://evil.example" https://yourdomain.com/api/me
  2. Look for Access-Control-Allow-Origin in the response.
  3. It's serious if it repeats your made-up origin and Access-Control-Allow-Credentials is true.

How to fix it

  1. List the exact origins allowed to call your API.
  2. Don't reflect the Origin header back without checking it.
  3. Only allow credentials for origins on that list.
  4. Test again with a made-up origin, and confirm your own site still works.

Prompt for your AI tool

Review this app's CORS settings. Replace any wildcard or reflected origin with a fixed list of the origins I actually use, and only allow credentials for those. Show me the final settings and how to test them.

Review what your AI tool changes, and test the live site afterward.

Catch this before a stranger does

AppLeakWatch keeps checking your live app and emails you when something new appears.

Start your 7-day trial

Common questions

Is Access-Control-Allow-Origin: * always unsafe?

Not always. It can be fine for truly public data with no cookies. It's wrong for anything tied to a signed-in user.

Does CORS protect my API from attackers?

No. It only guides browsers. Scripts and tools can call your API directly, so every route still needs a login check.

Related guides