For higher-risk methods such as PUT or DELETE, the browser sends an OPTIONS preflight first. The server must explicitly approve the origin, method, and any required headers before the real request proceeds. This handshake prevents the browser from blindly issuing destructive actions across domains and gives the server a chance to reject unsafe cross-origin operations early.
What the preflight handshake is actually doing
A preflight request is the browser’s way of asking permission before it sends a cross-origin request that could change state or include non-simple headers. The browser is not trying to complete the operation yet, it is checking whether the target server is willing to accept that origin, method, and header set. That makes the request a gate, not the real action.
The distinction matters because the preflight is deliberately conservative. A server can approve a browser request pattern that would otherwise be blocked by the same-origin policy, but it can also deny it before any sensitive method is issued. This is why the handshake is often invisible in normal use yet critical when a browser is asked to carry a destructive request across sites.
What the server must approve before the real request is allowed
For the actual request to proceed, the server has to return the right CORS response headers, including an explicit allowed origin and a compatible method and header set. If the response does not match what the browser asked for, the browser stops there and never sends the sensitive method. In practice, the browser is enforcing a policy decision made by the server, not making that decision itself.
That policy check is narrow by design. It does not mean the endpoint is generally safe, only that this browser-origin pair is permitted to continue. If the server over-broadly reflects origins, allows wildcard patterns where credentials are involved, or advertises methods it should not expose, the preflight becomes a weak control and the browser will still be allowed to proceed on an unsafe path.
Why this matters for destructive cross-origin operations
Methods such as PUT, PATCH, and DELETE can alter server state, so the preflight acts as an early warning barrier between the browser and the protected resource. It helps prevent a site from triggering unintended cross-domain side effects through a user’s browser session. The practical value is that unsafe actions are rejected before the request body and method ever reach application logic.
This is especially important when the request carries credentials or is part of an authenticated workflow. The browser is protecting the user from being used as a blind transport layer for a cross-site action. A successful preflight does not prove the action is legitimate, but it does mean the server has explicitly allowed the browser to attempt it under the configured CORS policy.
Risk and Threat Considerations
The main risk is misconfiguration, not the preflight mechanism itself. If a server trusts origins too broadly or treats CORS as an access control system, a browser can be persuaded to send a request that the application should never have accepted from that context.
Failure mechanism: An endpoint advertises an overly permissive CORS policy, then the browser honors that policy and sends the real cross-origin method, even though the operation is sensitive or state-changing.
Impact: Unwanted cross-site state changes, data exposure, or destructive actions can occur if the application assumes the preflight alone is sufficient protection.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while OWASP ASVS and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V10 — OAuth and OIDC | CORS preflight often gates browser-based cross-origin access flows. |
| Recommendation — Validate origin and token handling for browser-cross-origin requests before allowing sensitive operations. | ||
| NIST SP 800-53 Rev 5 | AC-3 — Access Enforcement | The topic centers on enforcing which cross-origin actions are permitted. |
| SC-7 — Boundary Protection | Preflight is part of controlling cross-origin boundary crossings. | |
| Recommendation — Enforce server-side access decisions on the protected method, not just browser preflight approval. Restrict cross-boundary browser requests to approved origins and methods only. | ||
| OWASP API Security Top 10 | API8 — Security Misconfiguration | Overly permissive CORS rules are a classic API misconfiguration risk. |
| Recommendation — Review CORS policy settings for overly broad origin, method, or header allowances. | ||
Practitioner Guidance
What to verify: Confirm that the server’s allowed-origin, allowed-method, and allowed-header rules are intentionally narrow for sensitive endpoints, and that credentialed requests are not paired with wildcard-style approval.
Common mistake: Treating CORS as the control that protects the action, when it really only tells the browser whether it may proceed. The application still needs its own authorization checks on the real request.
Practitioner takeaway: A passing preflight is not a security guarantee, it is only a browser-side permission check, so the real safeguard is strict server-side validation of who may perform the method and under what conditions.
Related resources from NHI Mgmt Group
- What is the difference between DNS rebinding and a normal cross-origin browser request?
- What happens when Bandit findings are not reviewed before a pull request is merged?
- How should security teams handle untrusted Flask request parameters before they reach sensitive code paths?
- What happens when contractors or BYOD users access sensitive apps without browser-level controls?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
