Modern applications rarely live on one domain. A web app may load its interface from one server, pull data from an API on another, and stream media from a third. Browsers treat each as a separate origin and, by default, stop scripts from reading data across those boundaries.
Cross-Origin Resource Sharing (CORS) decides when a boundary can be crossed. It is often called a browser feature, but that undersells it. CORS is an access control mechanism: well-configured, it connects trusted apps; badly configured, it can expose sensitive data. Wondering what CORS is, or why a weak policy keeps surfacing in security reviews? This guide answers both.

What is CORS?

CORS stands for Cross-Origin Resource Sharing. It is an HTTP-header-based mechanism that enables the server to allow or restrict access from any other origins. A protocol, domain name, port, or scheme requesting a URL that is different from the current page address depicts a cross-origin request. For security reasons, browsers implement the Same-Origin Policy and restrict cross-origin HTTP requests by default.

CORS helps in relaxing these default policies and enables easy cross-origin access. It bypasses the Same Origin Policy without decreasing security. Cross-origin requests can be made from different domains, subdomains, ports, or protocols (HTTPS and HTTP). So, when a request is made from one server to access resources from another server, the request is blocked/allowed when a CORS policy is implemented (depending on the settings).

Why CORS Exists and Why It’s Critical for Web Security?

To see why CORS matters, look at the rule it modifies and the problems it prevents.

Same-Origin Policy (SOP)

The Same-Origin Policy is the rule CORS builds on. It stops a script on one origin from reading content owned by another, so a malicious page cannot read your banking session in another tab.

Enabling Legitimate Interactions

Total isolation would break the web. Single-page apps, third-party APIs, and payment gateways all need cross-origin calls. CORS lets these happen deliberately, only for the origins a server trusts.

Preventing Unauthorized Access

CORS keeps the default answer as no. Unless a server explicitly allows an origin, the browser will not let its JavaScript read the response. Permission is granted, never assumed.

Mitigating Specific Attacks

By controlling which origins can read responses, CORS makes stealing authenticated API data harder. It does not replace authentication, though. It removes an easy path, not everyone’s.

Enforced by the Browser

Teams often miss this. CORS is enforced by the browser, not the server. The server only describes its policy in headers, and the browser decides whether to release the response. Requests made outside a browser are not covered at all.

Controlled Sharing

The goal is controlled sharing, not open access. A sound policy lists the trusted origins, methods, and headers, then blocks everything else. CORS works as a precise allowlist, not a switch.

How does Cross-Origin Resource Sharing Work? A Step-by-Step Breakdown

Here is what happens when a page requests a resource from another origin:

  1. A web page uses JavaScript to request a resource from a different origin. This resource can be a domain, protocol, or port.
  2. An Origin header is tagged on this request by the internet browser. It states where the request came from. This origin header cannot be spoofed by the web page.
  3. If the web page requests anything more than the basic demands, then the browser sends an Options request first to ask the server what is allowed. This is called a preflight request.
  4. On receiving the preflight request, the server sends Access-Control headers. This tells the browsers which requests are allowed.
  5. The browser checks these rules. If the origin is allowed, the request proceeds; otherwise, the response is blocked.
  6. On a match, the JavaScript receives the response. Otherwise, the browser raises a CORS error.

Types of CORS Requests (Simple vs Preflight Requests Explained)

Let us look at different scenarios to understand the types of CORS requests:

  • Simple Requests –

    Supports GET, HEAD, POST methods. These requests are fairly straightforward and do not contain custom headers. Two scenarios can play out here.
    For example, when a browser makes a request for a resource, it adds an origin header to the request message. If that request goes to a server of the same origin, then it is allowed.

    Another example here could be a cross-domain request. Imagine if a browser like xyz.com sends a request to abc.com. Here HTTP headers are checked to determine whether the request should go through or not.

    The request would go as:

    • Origin: http://xyz.com

    A response from the destination would be either of the following:

    1. Access- Control-Allow-Origin: http://xyz.com (which conveys that this domain is allowed)
    2. Access-Control-Allow-Origin: * (which conveys that all domains are allowed)
    3. An error if the cross-origin requests are not allowed (which conveys that access is not allowed)

  • Preflight Requests –

    It is used for more complicated, specific types of requests. The main purpose of this request is to determine if the server supports the main request that is about to be made. On receiving confirmation, the actual request is sent.
    For example, if a request is made to a different URL, then it qualifies as a cross-origin request. When sending a response, the server will add the Access-Control-Allow-Origin header. Its value needs to be matched to the origin header on the request, or it can be a wildcard (*) which allows any URL to make a request. Post this, the actual call is executed.

    A request is preflighted in one of the three cases:

    1. Uses an HTTP method other than GET or POST
    2. Comes with custom headers
    3. Has a MIME type other than text/plain

    So, if we use the same example as above with additional considerations, something like the following can be expected:

    The request would go as:

    1. Origin: http://xyz.com
    2. Access-Control-Request-Method: POST
    3. Access-Control-Request-Headers: X-Custom-Header

    A response from the destination (if it accepts the request) would be:

    1. Access-Control-Allow-Origin: http://xyz.com
    2. Access-Control-Allow-Methods: GET, POST
    3. Access-Control-Allow-Headers: X-Custom-Header

Understanding Request/Response headers:

Understanding the components present in the request and response headers will help provide better context in terms of what information is shared between two parties before allowing/restricting access to any resources.

Request Headers are:

  • Origin: <origin>: is the origin of the request.
  • Access-Control-Request-Method: <method>: is used in a preflight request to indicate the HTTP method that will be used to make the request.
  • Access-Control-Request-Headers: <header>: is used in a preflight request to indicate the HTTP headers (custom headers) that will be used to make the request.

Response Headers are:

  • Access-Control-Allow-Origin: <origin>: is used to specify the origin allowed to access the resource on the server. It can be a web url or * to allow all origins.
  • Access-Control-Expose-Headers: <headers>: lists the headers the browser has access to.
  • Access-Control-Max-Age: <seconds>: is the duration for which the response of a preflight request can be cached.
  • Access-Control-Allow-Methods: <methods>: indicates the method(s) that are allowed when attempting to access a resource.
  • Access-Control-Allow-Headers: <headers>: indicates the HTTP headers that can be used in a request.

Common CORS Misconfigurations and Security Risks

Most CORS problems come from settings that are too permissive. A weak policy turns protection into exposure. These patterns create a CORS vulnerability.

  • Reflecting any origin.

    The server echoes the Origin header back into Access-Control-Allow-Origin, trusting every site. With credentials on, an attacker’s page can read a signed-in user’s data.

  • Wildcards on sensitive endpoints.

    A wildcard on an API that returns private data exposes it to any origin. Wildcards belong on public resources only.

  • Trusting the null origin.

    It looks harmless, but attackers can produce null from sandboxed iframes, so keep it off the allowlist.

  • Weak origin matching.

    Loose checks let an attacker register a lookalike domain that passes. Sloppy substring or regex matches are a frequent CORS vulnerability.

  • Over-trusting subdomains.

    Trust every subdomain, and one weak subdomain can be turned against the main app.

What are Some CORS Best Practices?

  • Keep an allow list of trusted origins and match them strictly. Do not leave the origin header unchecked.
  • Reserve the wildcard for public, non-sensitive resources.
  • Never pair credentials with a wildcard or reflected origin. Name the exact origin.
  • Only allow the methods and headers you actually use and drop anything left from testing.
  • Do not treat CORS as authentication. Keep real access controls behind it.
  • Reject the null origin and avoid trusting whole subdomain trees.
  • Recheck the configuration whenever you add a domain, API, or integration.

How DoveRunner Secures API-Driven Content Ecosystems

Secure streaming runs on APIs, and those APIs stay safe only when cross-origin access is controlled with care. The discipline behind a good CORS policy, trusting only what you should and verifying each request, runs through any strong content security stack.

DoveRunner works in this space. Its focus is secure OTT and protected media delivery, built on multi-DRM, secure streaming workflows, and API-driven integration through SDKs and cloud services. Locking that ecosystem down takes the same deliberate approach to access that a sound CORS policy reflects.

CORS is one layer. It works best when cross-origin access is treated as a security decision, not a setting to switch on.

FAQs About  Cross-origin Resource Sharing (CORS)

What is Cross-Origin Resource Sharing (CORS)?

It is an HTTP header mechanism that tells the browser which outside origins may read a server’s resources, safely relaxing the Same-Origin Policy.

What is a Cross-Origin Resource Sharing (CORS) policy?

It is the set of rules a server sets through Access-Control headers: which origins, methods, and headers are allowed, and whether credentials may be sent.

What is the difference between REST and CORS?

REST is a style for designing APIs; CORS is a browser rule for cross-origin access. Different problems, often used together.

What is the difference between CORS and JSONP?

JSONP was an older, GET-only workaround using script tags. CORS replaces it with support for every method and proper error handling.

What vulnerabilities can arise from CORS misconfigurations?

Common causes of a CORS vulnerability are reflected origins, credentials paired with a wildcard, a trusted null origin, and weak origin matching.

How can you test Cross-Origin Resource Sharing (CORS)?

You can test CORS by looking at the Access-Control response headers in your browser’s dev tools. You can also request a test Origin to your server.

How can CORS-based attacks be prevented?

Firstly, use a strict allowlist of exact origins. Never put wildcards on sensitive endpoints. You should never mix credentials with a reflected origin and back it with real authentication.