What a preflight asks

Before some cross-origin requests, a browser sends an OPTIONS request to ask whether the server permits the origin, method, and request headers. The Fetch Standard defines this CORS protocol. Preflight is not sent for every cross-origin request: methods and headers outside the CORS safelist, or a content type such as application/json that is not safelisted, can trigger it. The browser evaluates response headers such as Access-Control-Allow-Origin, Access-Control-Allow-Methods, and Access-Control-Allow-Headers before deciding whether to send the actual request.

Caching is not authorization

Access-Control-Max-Age lets a server suggest how long a successful preflight result may be reused. Browsers can impose their own maximums and cache behavior, so the requested duration is not a guarantee. The preflight cache is also distinct from an ordinary HTTP response cache. Servers must authenticate, authorize, and validate the actual request independently. A successful OPTIONS response does not mean the subsequent request will succeed or that the caller is entitled to the data.

Credentials and origin matching

For cookies or HTTP authentication to accompany a cross-origin request, the client’s credentials mode and the server’s Access-Control-Allow-Credentials: true must align. A credentialed response cannot use Access-Control-Allow-Origin: *. Reflecting any supplied Origin is not a safe allowlist; compare against explicitly trusted origins and consider Vary: Origin for dynamically selected responses. CORS headers decide whether browser JavaScript may read a response. They do not replace server-side access control.

OWASP security expert guidance on CSRF

OWASP security experts warn against treating CORS as a general CSRF defense in their prevention guidance. Form-like safelisted requests can reach a server without a preflight, and a CORS failure can prevent a script from reading the response without proving that the request was never processed. Protect state-changing operations with server-side controls suited to the threat model, such as CSRF tokens, appropriate SameSite cookie settings, and Origin or Referer validation. Sites that rely on ambient cookies must not infer “no CSRF” from a restricted CORS response policy.

A practical review

Use browser developer tools to inspect OPTIONS and the actual request separately. Test the allowed origin, methods, headers, and credential combinations; look for wildcard or reflected origins; and verify whether the server performs a state change after a failed preflight scenario. The security perspective here comes from OWASP’s CSRF analysis, while the Fetch Standard defines protocol behavior. Those sources answer different questions.

References