¿Por qué los navegadores envían solicitudes preflight OPTIONS en CORS?
Los navegadores envían solicitudes previas OPTIONS antes de solicitudes complejas (como aquellas con headers Authorization o Content-Type: application/json) para comprobar si el servidor de destino autoriza el método y los headers antes de transmitir datos que puedan modificar el estado.
Detailed Technical Explanation
El mecanismo de preflight de CORS protege a servidores legacy que no fueron diseñados para solicitudes cross-origin. Si una solicitud no califica como "Simple Request" (por ejemplo, si utiliza métodos PUT/DELETE o headers personalizados), el navegador detiene la petición y envía un sondeo OPTIONS con Access-Control-Request-Method y Access-Control-Request-Headers.
Technical Example & Code
El navegador verifica la política CORS antes de despachar el payload real de la solicitud.
// 1. Browser sends Preflight Request:
OPTIONS /api/orders HTTP/1.1
Host: api.example.com
Origin: https://app.curious-techie.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: content-type, authorization
// 2. Server approves the interaction:
HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://app.curious-techie.com
Access-Control-Allow-Methods: GET, POST, OPTIONS
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Max-Age: 86400
// 3. Browser now automatically sends the actual POST request!Why This Is the Case (Underlying Architectural Rationale)
"Garantizar que servidores heredados no ejecuten mutaciones de estado no deseadas causadas por navegadores modernos que realizan llamadas cross-origin complejas."
Common Misconception vs Reality
"El preflight es una medida de seguridad del servidor para bloquear herramientas como cURL o Postman."
CORS es una restricción implementada estrictamente por el navegador para proteger al usuario; clientes HTTP de backend o cURL no envían preflight ni respetan CORS.
Related Curious-Techie Resources
How to Fix CORS Preflight Errors: Step-by-Step Guide →
Diagnose and resolve preflight 403 Forbidden errors, missing headers, and proxy redirection bugs.
Interactive ToolCORS Checker & Header Generator →
Test preflight OPTIONS handling and generate production-ready Express and Nginx CORS rules.
Developer ReferenceCORS Headers Reference & Specifications →
Related Questions in the Q&A Knowledge Base
CORS allows standard GET requests without a preflight check for backward compatibility with the legacy web. Because HTML tags like `<form>`, `<img>`, and `<script>` have always been able to issue cross-origin GET requests without pre-approval, requiring preflights for all GETs would have broken decades of existing web architecture.
HTTP 401 Unauthorized means the user is not authenticated (identity unknown; credentials missing or invalid), whereas HTTP 403 Forbidden means the user is authenticated (identity known), but lacks the necessary permissions to access the requested resource.
Using 'unsafe-inline' in a Content Security Policy defeats XSS protection because it instructs the browser to execute any inline script found in the HTML. Since Cross-Site Scripting works by injecting malicious inline script tags or event handlers, 'unsafe-inline' allows the attacker's payload to run freely.
Ecosistema Técnico Relacionado y Próximos Pasos
Artículos Técnicos Relacionados
What Is CORS (Cross-Origin Resource Sharing)?
The standard protocol enabling controlled cross-origin data access in modern browsers.
CSP vs CORS: Differences in Browser Defense Mechanisms
Distinguishing outbound resource loading restrictions from inbound server access control.
Troubleshooting: No Access-Control-Allow-Origin Header Present
Diagnose and fix the most common browser cross-origin blocking error with production configs.
Laboratorios Prácticos de Diagnóstico
Especificaciones y Referencias Técnicas
Continuar Aprendiendo
CORS Policy & Preflight Handshake Lab
Simulate preflight OPTIONS probes and adjust Access-Control-Allow-* headers inside the browser sandbox.