Understanding Same-Origin Policy and CORS in Web Development

Recently the author encountered a high‑frequency front‑end interview question about POST requests during a ByteDance interview and decided to explain the underlying concepts, starting with the same‑origin policy.

The same‑origin policy is a core browser security mechanism that restricts how a document or its scripts can interact with resources from another origin; an origin is defined by identical protocol, host, and port. Without such restrictions, attacks like XSS, SQL injection, OS command injection, HTTP header injection, and CSRF could endanger user data.

Same‑origin enforcement manifests in three areas: DOM access, web‑data access (e.g., XMLHttpRequest or Fetch), and network communication. Browsers block cross‑origin script‑initiated HTTP requests unless the server explicitly permits them via CORS headers.

CORS (Cross‑Origin Resource Sharing) allows controlled cross‑origin requests. When a request is not a “simple request,” the browser first sends a preflight OPTIONS request containing Access-Control-Request-Method and Access-Control-Request-Headers . The server responds with headers such as Access-Control-Allow-Origin , Access-Control-Allow-Methods , and Access-Control-Allow-Headers to indicate which origins, methods, and headers are permitted.

Simple requests are those that use only GET, HEAD, or POST methods, include only a limited set of safe headers, and do not involve custom streams or event listeners. If these conditions are met, no preflight is performed.

When credentials (e.g., cookies) are included, the server must not use a wildcard (*) for Access-Control-Allow-Origin or other headers; it must specify the exact allowed origin to prevent credential leakage.

In summary, the preflight request is an automatic OPTIONS request issued by browsers during CORS interactions to ensure security; the server’s response determines whether the actual cross‑origin request can proceed, thereby protecting user data and privacy.