Common Cors Misconfiguration mistakes that still ship

I have cleaned too many launch docs that say "CORS enabled" in a single checkbox. Enabled is not configured. Configured is not reviewed. Reviewed is not what an untrusted Origin receives on the public API. Thin security notes read like thin meta descriptions: the field exists, the substance does not.

SlaySlop's CORS misconfiguration check "Checks whether cross-origin resource sharing allows untrusted sites to read responses." The mistakes below still ship because teams optimize for their own SPA console going quiet.

Outcome if you catch these early

You ship an allowlist you can explain in one paragraph, with evidence from the live host. Editors and PMs can repeat that paragraph without inventing header folklore. Answer engines will not parse your ACAO header, but client security questionnaires will.

Boundaries

Read-only. Permissioned. Not a pentest. CORS sits under Security next to CSP and frame protection. Closing a CORS finding does not retire a missing CSP. SlaySlop does not edit the target. Only scan hosts you are authorized to assess.

Mistake 1: reflect any Origin

Dynamic ACAO that echoes the request Origin is the shortcut that demos well. It also answers the check's question the wrong way when that Origin is untrusted. If you need dynamic reflection, hard-allow only known front-end origins and reject the rest.

# Permissioned: does the API echo an arbitrary Origin?
curl -sI -H "Origin: https://untrusted.example" \
  "https://api.example.com/v1/me" \
  | awk 'BEGIN{IGNORECASE=1} /^access-control-allow-origin:/{print}'

Mistake 2: wildcard thinking next to credentials

Access-Control-Allow-Origin: * can be fine for truly public, non-credentialed responses. Pairing broad sharing with Access-Control-Allow-Credentials: true is the shape teams ship by accident when copying Stack Overflow answers into gateway config. Read both headers together. Always.

Mistake 3: only testing the first-party SPA

Your app origin is supposed to work. That test never asks about untrusted sites. Add one negative probe Origin to the handoff script. Write down both results. Scanners that observe public CORS behavior are doing the negative probe you skipped.

Mistake 4: fixing OPTIONS only

Preflight passes. Actual GET still reflects. Or the reverse. Glance at one method and you ship the other. Include the real method your SPA uses in the note, not only the OPTIONS dance you ran once.

Mistake 5: treating a console CORS error as proof of safety

Red text in DevTools means the browser withheld the response from your script. It does not mean the response lacked a generous ACAO for a different Origin. Look at headers. Prefer evidence from SlaySlop findings or your own permissioned probes over folklore from a failed local fetch.

Mistake 6: marketing site only in the scan

The handoff URL is www.example.com while the API is api.example.com. Cookie banners look great. CORS lives on the API. Paste the hosts that matter, with permission, or the Security row will stay quiet for the wrong reason.

Happy path that avoids the list

1. Enumerate public app and API hosts in the SOW.
2. Probe intended and untrusted Origins on sensitive routes.
3. Compare to CORS misconfiguration evidence in SlaySlop.
4. Check CSP and frame protection on the same pass.
5. Document the allowlist where the next engineer will find it.

Documentation mistakes that look like config mistakes

Sometimes the gateway is fine and the runbook is wrong. The runbook says "set ACAO to *" for local demos. A tired engineer applies the runbook to production. The mistake shipped as documentation culture, not as a missing WAF rule.

Fix the runbook in the same PR when you tighten the allowlist. Otherwise the next on-call will reintroduce the grant while "following the docs." Scannable internal docs beat tribal knowledge for the same reason scannable meta descriptions beat keyword stuffing: clarity travels.

Framework defaults are not a policy

Copying a framework sample that reflects Origin for local DX is fine in development. Shipping that sample unchanged is a mistake that still clears code review when reviewers only boot the SPA. Add a negative Origin test to CI or to the handoff script. Even a one-line curl in the release checklist beats another retrospective about "temporary" reflection.

Priya-mode editorial note: if your public security page claims "strict CORS," the allowlist should be describable in public language without lying. Vague marketing claims plus reflective APIs are a trust problem waiting for a questionnaire.

Related next step

When a finding fires, reproduce with the same Origin and route before changing global gateway defaults. Soft read: CORS misconfiguration and the checks catalog.