Understanding Same‑Origin Policy and CORS in Frontend Development

Preface

Recently the author encountered a high‑frequency interview question about POST requests during a ByteDance interview, which touches many knowledge points in everyday frontend development. The following content explains the related concepts in detail.

Same‑Origin Policy

Browsers can load many resources (JavaScript, images, audio, video, etc.) from any origin, but unrestricted access would lead to security issues such as XSS, SQL injection, OS command injection, HTTP header injection, CSRF, and others. Therefore browsers enforce the same‑origin policy to protect user privacy and data security.

The same‑origin policy restricts a document or its scripts to interact only with resources that share the same protocol, host, and port.

Protocol: e.g., HTTP, HTTPS.

Host: the networked computer providing services.

Port: the communication endpoint between processes.

For example, the URL http://test.home.com:8080/dir/page.html is compared with other URLs to illustrate same‑origin checks.

The policy manifests in three areas: DOM access, web data (XHR/Fetch), and network communication.

DOM access restriction: scripts cannot read or manipulate the DOM of a page from a different origin.

Web data restriction: XHR/Fetch can only request resources from the same origin unless CORS headers are used.

Network communication restriction: browsers block cross‑origin network responses unless allowed.

Because of these restrictions, browsers only allow same‑origin HTTP requests from scripts unless the server explicitly permits cross‑origin requests via CORS.

CORS

CORS (Cross‑Origin Resource Sharing) is a mechanism that allows controlled cross‑origin requests. Browsers may block the response even if the request is sent, so CORS provides a way for the server to indicate which origins are allowed.

“CORB is a security mechanism that prevents malicious cross‑origin responses from being accessed by the rendering process.”

When a page sends an AJAX request to another domain, the browser may intercept the response if it deems the data unsafe.

CORS works by the server adding specific HTTP headers to the response. The browser first sends a preflight OPTIONS request to ask for permission, and the server replies with headers such as Access-Control-Allow-Origin , Access-Control-Allow-Methods , and Access-Control-Allow-Headers .

Simple Request

A request that meets all of the following conditions is considered a simple request and does not trigger a preflight:

Only uses GET, HEAD, or POST.

Only uses standard headers (Accept, Accept‑Language, Content‑Language, Last‑Event‑ID, Content‑Type with limited values, DPR, Download, Save‑Data, Viewport‑Width, Width).

Does not use a ReadableStream object.

No custom request headers.

No event listeners on XMLHttpRequestUpload .

Preflight Request

Non‑simple requests trigger a preflight request: the browser sends an OPTIONS request first to determine whether the actual request is safe.

The preflight request includes two special headers:

Access-Control-Request-Method : the HTTP method that will be used (e.g., POST).

Access-Control-Request-Headers : a comma‑separated list of additional headers the actual request will send (e.g., content-type,x-secsdk-csrf-token ).

The server’s response may also contain:

Access-Control-Allow-Origin : specifies the allowed origin (or * for any).

Access-Control-Max-Age : how long the preflight result can be cached (e.g., 86400 seconds = 1 day).

After a successful preflight, subsequent actual requests behave like simple requests, including an Origin header and the server’s Access-Control-Allow-Origin header in the response.

Requests with Credentials and Wildcards

When credentials (e.g., cookies) are included, the server must not use a wildcard * for Access-Control-Allow-Origin ; it must echo back the specific requesting origin. Similarly, Access-Control-Allow-Headers and Access-Control-Allow-Methods should list explicit values rather than * to avoid security risks.

Full Request Flow Diagram

Conclusion

The preflight request is an automatic OPTIONS request sent by browsers during CORS to ensure security and let the server decide whether to allow the cross‑origin request.

Cross‑origin requests are blocked by default due to the same‑origin policy; when a page needs to access a different origin, the browser first performs a preflight to verify the server’s permissions.

The preflight includes extra headers such as Origin and Access-Control-Request-Method . If the server approves, it returns the appropriate Access-Control-Allow-* headers, after which the browser proceeds with the actual request.

Using the preflight mechanism effectively mitigates security risks associated with cross‑origin requests, protecting user data and privacy.