Por que os navegadores enviam requisições preflight OPTIONS no CORS?
Os navegadores enviam requisições prévias OPTIONS antes de requisições complexas (como aquelas com Authorization ou Content-Type: application/json) para verificar se o servidor permite o método e os cabeçalhos antes de enviar dados que alterem o estado.
Detailed Technical Explanation
O preflight protege servidores legados que não esperavam requisições cross-origin. Quando uma requisição não é considerada simples, o navegador interrompe o fluxo e realiza uma sondagem OPTIONS para validar as permissões de acesso.
Technical Example & Code
O navegador consulta as permissões CORS antes de despachar a requisição real.
// 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)
"Evitar que ações com efeitos colaterais no servidor sejam executadas sem que o servidor declare expressamente suporte a cross-origin."
Common Misconception vs Reality
"O preflight CORS protege a API contra requisições feitas por cURL ou Postman."
CORS é uma regra imposta exclusivamente pelos navegadores; ferramentas de linha de comando não executam preflight e não são bloqueadas por 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.
Ecossistema Técnico Relacionado e Próximos Passos
Artigos 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.
Laboratórios Práticos de Diagnóstico
Especificações e Referências para Desenvolvedores
Continuar Aprendendo
CORS Policy & Preflight Handshake Lab
Simulate preflight OPTIONS probes and adjust Access-Control-Allow-* headers inside the browser sandbox.