CORS Preflight in Practice: Credentials, Simple Requests & Misconfigurations
Learn the interview-ready mental model, practical trade-offs, and production patterns for this web fundamentals topic.
Topic content
CORS preflight requests are sent by the browser for non-simple cross-origin requests (PUT, DELETE, custom headers, application/json). Understanding when preflight happens, how credentials affect behavior, and common server misconfigurations is essential for debugging cross-origin issues.
The browser acts like a security guard. Before allowing a complex request (non-simple), it first asks the server: 'Is this origin, method, and these headers allowed?' If the server says yes, the real request proceeds. Credentialed requests make the rules stricter.
1Simple vs Preflight Requests
Simple requests (GET, HEAD, POST with basic Content-Type and no custom headers) are sent directly. Non-simple requests trigger a preflight OPTIONS request first.
2Credentialed CORS Requests
When credentials: 'include' is used, the server must return a specific origin (no wildcard *) and Access-Control-Allow-Credentials: true.
3Common CORS Misconfigurations
Missing headers on actual response (not just preflight), using wildcard with credentials, incorrect Access-Control-Allow-Headers, and proxy/CDN stripping headers.
- ✓Preflight happens for non-simple requests (custom methods/headers)
- ✓Credentialed requests require specific origin + Allow-Credentials: true
- ✓Wildcard (*) cannot be used with credentials
- ✓Check both preflight and actual response headers
- ✓Proxies/CDNs can strip CORS headers — verify the full chain
- ✓Always test cross-origin flows in real browsers