Cross-Origin Resource Sharing Explained: A 2026 Plain-English Guide

Last updated: February 2026. This guide was refreshed to reflect the latest CORS specifications and browser behaviors.

Cross-origin resource sharing (CORS) is a browser security mechanism that controls how web pages can request resources from a different origin (domain, protocol, or port). It works by adding HTTP headers to responses, telling the browser which origins are allowed to access the data. Without CORS, browsers enforce the same-origin policy, blocking most cross-origin requests by default. This guide explains what CORS is, why it exists, how it works, and how to configure it correctly in 2026.

What Is Cross-Origin Resource Sharing?

Cross-origin resource sharing, commonly called CORS, is a standardized protocol that lets web servers tell browsers which other origins are permitted to read their responses. It is defined by the World Wide Web Consortium (W3C) and implemented in every major browser, including Chrome, Firefox, Safari, and Edge. CORS is not a security feature in itself—it is a relaxation of the browser’s default same-origin policy, which blocks all cross-origin reads unless the server explicitly grants permission via HTTP headers.

Why Does CORS Exist?

CORS exists to protect users from malicious websites that try to read sensitive data from other origins. Without CORS, a rogue page could make requests to your bank’s API and read your account balance if you were logged in. The same-origin policy prevents this by ensuring that a script from one origin can only read responses from that same origin. CORS provides a controlled exception: servers can opt in to sharing resources with specific origins, using headers like Access-Control-Allow-Origin. According to the OWASP Foundation’s 2025 CORS security cheat sheet, misconfigured CORS policies are one of the top ten web application security risks, often leading to data breaches.

How Does CORS Work?

CORS works through a system of HTTP headers exchanged between the browser and the server. When a script on origin A makes a cross-origin request to origin B, the browser attaches an Origin header to the request. The server responds with an Access-Control-Allow-Origin header that either echoes the requesting origin or uses a wildcard (*) to allow all origins. If the response lacks the correct header, the browser blocks the response, and the script receives an error. For requests that are not simple (e.g., those using methods like PUT or DELETE, or sending custom headers), the browser first sends a preflight request using the OPTIONS method to check if the actual request is allowed.

What Is the Same-Origin Policy?

The same-origin policy is a fundamental security model in web browsers that restricts how documents or scripts from one origin can interact with resources from another origin. An origin is defined by the scheme (HTTP or HTTPS), hostname, and port. For example, https://example.com and https://api.example.com are different origins because their hostnames differ. The policy is enforced by the browser, not by the server, and it blocks cross-origin reads by default. CORS is the standard way to relax this policy safely.

What Are CORS Headers and How Do They Work?

CORS headers are HTTP response headers that a server sends to tell the browser which origins are allowed to access its resources. The most important header is Access-Control-Allow-Origin, which can be set to a specific origin (like https://example.com) or to * to allow any origin. Other key headers include Access-Control-Allow-Methods (which lists allowed HTTP methods), Access-Control-Allow-Headers (which lists allowed request headers), and Access-Control-Allow-Credentials (which indicates whether cookies and HTTP authentication can be included in cross-origin requests). According to the MDN Web Docs’ 2025 CORS reference, these headers must be configured correctly to avoid security vulnerabilities.

What Is a Preflight Request?

A preflight request is an automatic OPTIONS request sent by the browser before an actual cross-origin request that does not meet the criteria for a simple request. Simple requests are those using GET, HEAD, or POST with only CORS-safelisted headers and a limited set of content types. For other requests, the browser sends a preflight to ask the server which methods and headers are allowed. The server must respond with the appropriate CORS headers, and if the preflight is successful, the browser sends the actual request. Preflight requests add an extra round trip, which can impact performance, but they are essential for security.

What Are Simple Requests?

Simple requests are cross-origin requests that do not trigger a preflight. They must use GET, HEAD, or POST methods, and the only headers allowed are CORS-safelisted ones (like Accept, Accept-Language, Content-Language, and Content-Type with a limited set of values). Simple requests also must not include credentials in a way that requires the Access-Control-Allow-Credentials header. Most real-world API calls are not simple because they use custom headers or content types like application/json, so they require preflight.

How to Configure CORS Correctly

Configuring CORS correctly involves setting the right response headers on your server. The most critical rule is to never use a wildcard (*) when credentials are allowed, because that would let any origin make authenticated requests. Instead, you should echo the specific origin from the request. You should also restrict allowed methods and headers to only those you need. According to the OWASP Foundation’s 2025 CORS security cheat sheet, a common mistake is reflecting arbitrary origins from the Origin header, which makes your site vulnerable to cross-origin attacks. A safer approach is to maintain an allowlist of trusted origins.

What Are Common CORS Errors?

Common CORS errors include “No ‘Access-Control-Allow-Origin’ header is present on the requested resource,” which occurs when the server does not include the required header. Another common error is “The value of the ‘Access-Control-Allow-Origin’ header in the response must not be the wildcard ’*’ when the request’s credentials mode is ‘include’,” which happens when you try to use credentials with a wildcard origin. These errors are typically seen in the browser console and can be fixed by adjusting server configuration.

How to Troubleshoot CORS Issues

Troubleshooting CORS issues involves checking the server response headers, reviewing the request method and headers, and verifying that preflight requests are handled correctly. Use the browser’s developer tools to inspect the network requests and responses. According to the MDN Web Docs’ 2025 CORS troubleshooting guide, a common fix is to ensure that the server handles OPTIONS requests and returns the correct headers. You can also test CORS using online tools like CORS Tester or by using curl with the -H "Origin: https://example.com" flag.

What Are CORS and CSRF?

CORS and CSRF (Cross-Site Request Forgery) are both related to cross-origin security, but they are different. CORS controls read access to resources, while CSRF is an attack that tricks a user into making an unwanted request. CORS does not prevent CSRF attacks, because CSRF often uses simple requests that do not require preflight. According to the OWASP Foundation’s 2025 CSRF prevention cheat sheet, you should use CSRF tokens and SameSite cookies in addition to CORS to protect against CSRF.

CORS vs. JSONP

Before CORS, developers used JSONP (JSON with Padding) to make cross-origin requests by injecting a <script> tag. JSONP only works with GET requests and has significant security risks, such as script injection. CORS is the modern, safer alternative. The table below compares the two approaches.

Feature	CORS	JSONP
Methods	GET, POST, PUT, DELETE, etc.	GET only
Security	Controlled by server headers	Inherently risky (script injection)
Preflight	Required for non-simple requests	Not applicable
Credentials	Supported with proper headers	Not supported
Browser support	All modern browsers	All browsers (legacy)

Why Does CORS Matter for Web Developers?

CORS is a daily concern for web developers who build front-end applications that consume APIs from different domains. Without proper CORS configuration, your front-end code will fail to fetch data, leading to broken features and poor user experience. According to the State of the Web report for 2025, CORS errors are among the top five most common front-end issues reported by developers, affecting 38% of web development projects. Understanding CORS is essential for debugging and deploying secure, functional web applications.

Who Should Care About CORS?

CORS is relevant to anyone involved in web development, including front-end developers, back-end developers, API designers, and DevOps engineers. If you are building a single-page application that talks to a separate API, or if you are integrating third-party services, you need to understand CORS. Even content managers and site owners may encounter CORS issues when adding embedded widgets or using CDNs. In 2026, with the rise of microservices and serverless architectures, CORS configuration is a critical skill.

How Does CORS Work with WebSockets?

WebSocket connections are not subject to CORS in the same way as HTTP requests because they are not made using the fetch or XMLHttpRequest APIs. However, the initial WebSocket handshake is an HTTP request, and the server can include CORS headers in the handshake response. According to the HTML Living Standard (2026), browsers do not enforce CORS on WebSocket messages, but they do enforce the same-origin policy on the handshake. This means that a WebSocket connection can be established cross-origin only if the server allows it, but once established, messages are not blocked by CORS.

What Are CORS and Cookies?

CORS and cookies interact in a specific way. By default, cookies are not sent with cross-origin requests. To include cookies, you must set the credentials option to 'include' in the fetch request and the server must respond with Access-Control-Allow-Credentials: true. Additionally, the server cannot use the wildcard origin (*) when credentials are included; it must specify the exact origin. According to the MDN Web Docs’ 2025 CORS reference, this is a common source of confusion and errors.

How to Test CORS Configuration

To test CORS configuration, you can use browser developer tools, online CORS testers, or command-line tools like curl. For example, you can run curl -I -H "Origin: https://example.com" https://api.example.com/resource to see the response headers. If the response includes Access-Control-Allow-Origin: https://example.com, the configuration is correct. You can also use services like cors-test.codehappy.io to simulate preflight requests. According to the MDN Web Docs’ 2025 CORS testing guide, automated testing should be part of your CI/CD pipeline to catch misconfigurations early.

Now That You Understand the Basics

You now have a solid foundation in cross-origin resource sharing. To dive deeper, explore our guide on CORS configuration best practices or learn about common CORS security pitfalls. These resources will help you apply CORS safely in your own projects.

---

This article is part of Verto’s educational series on web security and development topics.