CORS Preflight Request

How CORS Preflight Requests Work

A CORS preflight request is not the cross-origin request itself, but a browser-side permission check. The browser sends an OPTIONS request first when the target request is non-simple, then compares the server’s response to the requested method, headers and origin before deciding whether to continue.

That behaviour matters because the browser is enforcing a policy boundary, not merely relaying traffic. The server must explicitly state what it will accept, and the browser will block the actual request if the response is missing, incomplete or inconsistent.

Why Browsers Use Preflight Checks

Preflight exists to reduce the risk of unexpected cross-origin actions. It gives the server a chance to say whether a request with custom headers, methods such as PUT or DELETE, or credentialed access is allowed, rather than letting the browser send the full request blindly.

This is why preflight sits at the intersection of usability and security. It enables controlled cross-origin interaction for modern web applications, while preserving the same-origin policy as the default protection model. The browser is effectively asking, “Should this origin be trusted to perform this action?”

For background on the browser boundary that makes this check necessary, see the Same-Origin Policy and Browser Security Model Guide.

What Server Responses Must Match

A valid preflight response must align with the intended request in a few specific ways. The allowed origin must be acceptable, the requested method must be permitted, and any non-simple request headers must be acknowledged. If credentials are involved, the response must also be compatible with credentialed cross-origin access rules.

Small mismatches can cause the browser to reject an otherwise reachable endpoint. That is why CORS issues often appear as browser errors even when the network path, DNS and application backend are all functioning normally.

Practical implementation details vary across frameworks and middleware, so configuration should be checked at the server edge rather than assumed from application code alone. The CORS Misconfiguration Guide covers the common policy mistakes that make preflight handling unsafe or unreliable.

Common Failure Modes and Security Consequences

Preflight failures usually come from policy confusion, not transport failure. Common causes include overbroad origin reflection, missing allowlists, inconsistent handling of requested headers, and server responses that differ between preflight and the actual request.

The security consequence is straightforward: if the policy is too permissive, a malicious site may gain cross-origin access that the application owner did not intend. If the policy is too restrictive or inconsistent, legitimate browser traffic breaks, and teams may respond by loosening controls until the application works again.

For standards context and browser platform guidance, the W3C is the primary reference point for the web security model that CORS builds on.

Risk and Threat Considerations

Preflight requests matter most when the server’s CORS policy is broader than the application’s real trust boundary. Misconfigured responses can let an untrusted origin probe capabilities, send privileged browser requests, or expose data through a policy gap that looks minor in code but major in practice.

Failure mechanism: The browser treats the preflight response as an authorization decision for cross-origin access, so a weak or inconsistent policy can be abused to bypass the intended origin boundary or to make the application behave as if it had approved a request it should have rejected.

Impact: The result can be unauthorized browser-driven access, data exposure, or the loss of a key control layer that was expected to limit which websites can interact with the application.

Practitioner Guidance

What to watch for: Treat preflight as a configuration control, not a formatting detail. Policy should be explicit, narrow and consistent across environments, because browser enforcement only helps when the server’s allow rules match the real security intent.

Practitioner takeaway: When CORS is involved, validate the preflight path and the actual request path together, because a correct OPTIONS response is only useful if it matches the endpoint’s real authorization posture.

Related resources from NHI Mgmt Group

• What breaks when CORS preflight handling is incomplete or inconsistent across an API estate?
• What breaks when Spring Security blocks preflight CORS requests before they reach the application layer?
• What is the difference between a simple CORS request and a preflighted request?
• What happens when a browser sends a preflight request before a sensitive cross-origin method?