Perché i browser inviano richieste preflight OPTIONS in CORS?
I browser inviano richieste preventive OPTIONS prima di richieste complesse (come quelle con header Authorization o Content-Type: application/json) per verificare che il server autorizzi il metodo e gli header prima di inviare dati che possono alterare lo stato.
Detailed Technical Explanation
Il meccanismo preflight tutela i server legacy non predisposti per richieste cross-origin. Se una chiamata HTTP non soddisfa i requisiti di una "Simple Request", il browser invia preventivamente una richiesta OPTIONS con gli header Access-Control-Request-*.
Technical Example & Code
Il browser verifica preventivamente che il server accetti le intestazioni richieste.
// 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)
"Evitare che client web inviino richieste potenzialmente dannose verso server che non hanno implementato controlli cross-origin."
Common Misconception vs Reality
"Il preflight protegge le API contro strumenti come cURL o Postman."
CORS è una protezione implementata esclusivamente dai browser per proteggere l’utente; i client backend o cURL non inviano preflight e ignorano le regole 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 Tecnico Correlato e Passaggi Successivi
Articoli Tecnici Correlati
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.
Laboratori Pratici di Diagnosi
Specifiche e Standard di Riferimento
Continua ad Imparare
CORS Policy & Preflight Handshake Lab
Simulate preflight OPTIONS probes and adjust Access-Control-Allow-* headers inside the browser sandbox.