CORS Preflight in Practice: Credentials, Simple Requests & Misconfigurations
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.
| Property | Simple Request | Preflight Request |
|---|---|---|
| Methods | GET, HEAD, POST (basic Content-Type) | PUT, DELETE, custom headers, application/json |
| Common Use | Basic data fetching | State-changing operations |
| Triggers Preflight | No | Yes (OPTIONS) |
Simple Request
Methods
GET, HEAD, POST (basic Content-Type)
Common Use
Basic data fetching
Triggers Preflight
No
Preflight Request
Methods
PUT, DELETE, custom headers, application/json
Common Use
State-changing operations
Triggers Preflight
Yes (OPTIONS)
Common questions
- ›“When does the browser send a preflight request?”
- ›“Why can't I use Access-Control-Allow-Origin: * with credentials?”
- ›“How do you fix a CORS error when using Authorization header?”
- ›“Explain credentialed CORS and its restrictions.”
What interviewers look for
- Clear distinction between simple and preflight requests
- Understanding of credentialed request rules
- Practical debugging mindset (preflight + actual response)
- Knowledge of common misconfigurations and proxies
Short answer (60 sec)
Preflight (OPTIONS) is sent before non-simple requests (PUT/DELETE, custom headers, JSON). For credentialed requests, the server must return a specific origin and Access-Control-Allow-Credentials: true. Wildcard origin is not allowed with credentials.
Detailed answer (senior level)
Simple requests go directly. Non-simple ones trigger preflight. Credentialed requests are stricter: no wildcard origin allowed. Common failures: missing headers on actual response, incorrect Allow-Headers, proxy/CDN stripping headers, or using * with credentials. Always check both preflight and real response in DevTools.
- Handling OPTIONS only but forgetting CORS headers on real response
- Using wildcard origin with credentials
- Forgetting to include custom headers in Access-Control-Allow-Headers
- Assuming all POST requests are simple (JSON often triggers preflight)
- Not testing with real credentials and cross-origin setup
- ✓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
Related web fundamentals topics
Continue with closely related browser and frontend engineering concepts.