CORS

What is CORS?

CORS, short for Cross-Origin Resource Sharing, is a security mechanism built into web browsers. It lets a server declare which origins (a combination of protocol, domain and port) are allowed to read its responses from JavaScript running on another origin. Without it, a script on https://app.example.com could not read the response of a request sent to https://api.example.com.

CORS exists because of the same-origin policy, which blocks cross-origin reads by default to protect users from malicious pages. CORS is the controlled way to relax that rule. It is enforced by the browser, not by the server: tools like curl or Postman ignore it.

How CORS works

When a page calls another origin, the browser adds an Origin header. The server answers with headers that say whether that origin is accepted. If the answer does not match, the browser blocks the response and logs a CORS error in the console, even though the request may have reached the server.

A minimal permissive response looks like this:

Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Methods: GET, POST, OPTIONS
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Max-Age: 86400

Simple requests and preflight

Simple requests (GET or POST with basic headers) are sent directly and the browser checks the response afterwards. Anything else, such as a PUT, a DELETE or a request carrying an Authorization header or a JSON body, triggers a preflight: the browser first sends an OPTIONS request to ask for permission. If the server does not answer it correctly, the real request is never sent.

• Access-Control-Allow-Origin: the origin allowed to read the response.
• Access-Control-Allow-Methods: the HTTP methods accepted.
• Access-Control-Allow-Headers: the request headers accepted.
• Access-Control-Allow-Credentials: whether cookies and credentials may be sent.
• Access-Control-Max-Age: how long the browser may cache the preflight result.

CORS vs related concepts

CORS is not an authentication system. It does not stop a script, a server or a bot from calling your API. It only controls what a browser lets a web page read.

Best practices and common errors

• List the exact origins you trust instead of using *, especially for authenticated APIs.
• Never combine Access-Control-Allow-Origin: * with credentials: browsers reject it.
• Answer the OPTIONS preflight with a 2xx status and the right headers, before any authentication step.
• Check that proxies, CDNs and API gateways do not strip or duplicate CORS headers.
• Add Vary: Origin when the allowed origin changes per request, so caches behave correctly.

The classic error "No 'Access-Control-Allow-Origin' header is present" almost always means the server (or an intermediate layer) is not returning the header for that origin or for the preflight.

CORS at BeBranded

Between a Webflow front end and a custom back end, an automation endpoint or a third-party API, CORS is one of the first integration details to get right. Our team configures it as part of the web apps we build, so that front end and API talk to each other securely without opening more access than needed.