CORS preflight

Slap yourself if

You think preflight is a browser bug, assume it’s optional, or try to ‘disable CORS’ from the frontend.

Why this exists

Because preflight requests quietly dominate latency, break integrations in production, and get misdiagnosed as server slowness or random browser behavior.

Mental model

CORS preflight is a permission check, not a data request. The browser asks the server for consent before sending a potentially dangerous cross-origin request.

  • The browser detects a non-simple cross-origin request.
  • It sends an OPTIONS preflight request without credentials or body.
  • The server responds with allowed methods, headers, and origins.
  • Only then does the browser decide whether to send the real request.
  • Adding custom headers that trigger preflight unintentionally.
  • Misconfiguring Access-Control-Allow-Headers.
  • Assuming 204/200 OPTIONS responses are interchangeable.
  • Forgetting that preflight responses are cached separately.

CORS preflight is a browser-enforced permission check using an OPTIONS request to verify that a cross-origin request is allowed before sending it.

  • Calls it an extra request the browser adds randomly.
  • Tries to fix it with frontend-only changes.
  • Ignores header-based triggers.
  • Assumes preflight always happens.

Deep dive

Requires Pro

Premium deep dives include more internals, more scars.

What actually triggers a preflight

Why preflight doubles perceived latency

Why preflight caching often doesn’t work

Why preflight exists and can’t be skipped

How CORS answers expose shallow security understanding