Cross-Origin Resource Sharing

cors · cross origin resource sharing · same-origin policy · access-control-allow-origin · preflight · cors headers

Definition

CORS is a browser security mechanism that restricts cross-origin requests; a personalization API must explicitly permit a client's domains through the Access-Control-Allow-Origin header.

The same-origin policy and why CORS exists

The browser enforces a same-origin policy: JavaScript loaded from shop.example.com cannot, by default, read responses from api.personalization.com. It is protection against attacks in which a malicious site could read data from other sites on behalf of a signed-in user.

CORS is the mechanism that lets a server explicitly permit requests from named origins, exempting them from the same-origin policy.

How CORS works

A simple request (a GET with no custom headers):
1. The browser sends the request with the header Origin: https://shop.example.com.
2. The server checks whether that origin is allowed.
3. If it is, it returns Access-Control-Allow-Origin: https://shop.example.com.
4. The browser passes the response through to the JS.

Preflight for complex requests:

OPTIONS /api/recommendations HTTP/1.1
Origin: https://shop.example.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: Content-Type, X-API-Key

The server has to answer:

Access-Control-Allow-Origin: https://shop.example.com
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: Content-Type, X-API-Key
Access-Control-Max-Age: 86400

CORS during a personalization platform integration

When a JavaScript recommendation widget is connected, the browser calls the personalization API on a different domain. If the server does not return the right CORS headers:

The browser blocks the response — not the request; the server does receive it
The console shows CORS policy: No 'Access-Control-Allow-Origin' header
Recommendations never appear, although everything works server-side

Important: a CORS error is only visible in a browser. Test the API with curl or Postman and everything works, because those tools do not implement the same-origin policy. Check the integration in a real browser with DevTools open.

Common configuration mistakes

Mistake	Symptom	Fix
No CORS header	Recommendations do not load	Add `Access-Control-Allow-Origin`
Wildcard plus credentials	Requests carrying cookies are blocked	Name the origin and add `Allow-Credentials: true`
OPTIONS not handled	Preflight returns 404	Add an OPTIONS handler to the router
The wrong domain	A CORS error on a subdomain	Allow `*.shop.example.com`, or each subdomain individually

Frequently asked questions

Why do recommendations fail to appear even though the API responds?

The usual cause is CORS. Open DevTools, go to the Network tab, find the request to the personalization API and check the response headers. If Access-Control-Allow-Origin is absent, the browser blocks the response on the client side — the server returned the data, but the JS never received it.

What is a preflight request?

Before a complex request — one with non-standard headers, the PUT or DELETE method, or a JSON content type — the browser automatically sends an OPTIONS request asking the server whether this kind of call is allowed from this origin. If the server does not answer OPTIONS correctly, the main request is never sent.

Is a wildcard Access-Control-Allow-Origin dangerous?

For a public API with no authentication it is acceptable. For an API that works with cookies or Authorization headers a wildcard is both unsafe and technically impossible: you cannot allow credentials and send an asterisk at the same time. The permitted origins have to be listed explicitly.