CORS Headers: Cross-Origin Resource Sharing Configuration Guide

The internet can feel like a minefield sometimes, but features like Cross-Origin Resource Sharing (CORS) are here to make things safer and more reliable. Of course, even the best tools have their flaws.

Did you know that a study of the top 1 million websites found that about 3.75% had CORS settings so loose they could expose sensitive user data? It’s a small percentage, but when you think about how many sites that includes, it’s a big deal.

CORS works by letting browsers control what web pages can request and share resources—like data, images, or scripts—with other domains. It acts as a kind of gatekeeper, sending a preflight request to check if the server says it’s okay before the real cross origin request goes through. But the way it’s set up really matters. Another study found that 93% of CORS vulnerabilities happen because settings are too open, leaving the door wide open for attackers to grab things like login credentials or other sensitive info.

In this article, we’ll dive into how CORS keeps different parts of the web working together smoothly and how it helps make browsing safer—when it’s done right. Let’s unpack why this security feature is so important and what we can learn from its challenges.

What is Cross-Origin Resource Sharing (CORS)?

Cross-Origin Resource Sharing (CORS) is a security feature in web browsers that decides how web pages from one domain can interact with resources—like data, images, or scripts—on another domain. Normally, browsers enforce something called the same-origin policy, which blocks these types of requests to prevent unauthorized access. CORS steps in to provide a way for servers to say, “Hey, it’s okay for this other domain to access these resources.”

Here’s how it works: when a browser tries to fetch something from a different domain, it sends a CORS request to the server hosting that resource. The server responds with headers—like Access-Control-Allow-Origin—to tell the browser whether it’s allowed. If the domain making the request matches what’s in this header, the browser lets it through. If not, the browser blocks it. The Origin header indicates the origin of the request and is validated against an access list to enhance security. It interacts with the Access-Control-Allow-Origin header to control access based on the requesting origin.

For example:

• To allow just one specific site, the server might send back: Access-Control-Allow-Origin: https://example.com.
• To allow any site (not recommended for production), it could use: Access-Control-Allow-Origin: *.

CORS serves two important purposes:

1. It blocks unauthorized access: By setting strict rules, CORS ensures only trusted domains can get to sensitive data.
2. It allows web apps to work together: Modern websites often rely on sharing resources between different domains, and CORS makes this possible in a secure way.

The tricky part is setting it up correctly. If you make it too open, you could accidentally let untrusted domains access your resources, which puts your data and users at risk. But when it’s done right, CORS acts like a reliable gatekeeper—keeping your web app secure while letting trusted domains share what they need.

How CORS Works

CORS operates by introducing new HTTP headers that allow servers to specify which origins are permitted to access their resources. When a script from one origin attempts to fetch data from another origin, the browser initiates a preflight request to the external server. This preflight request uses the HTTP method OPTIONS and includes several HTTP headers, such as Access-Control-Request-Method and Access-Control-Request-Headers.

The purpose of the preflight request is to check if the server permits the actual request. The server examines these headers to determine if the origin, HTTP method, and any custom headers are allowed. If the server approves, it responds with the appropriate CORS headers, such as Access-Control-Allow-Origin, Access-Control-Allow-Methods, and Access-Control-Allow-Headers. This response informs the browser that the actual request can proceed.

By validating these preflight request headers, CORS ensures that only authorized scripts from specified origins can access the server’s resources, thereby enhancing security and preventing unauthorized cross-origin access.

Cross-Origin Resource Sharing and Preflight Request

As we mentioned earlier CORS or Cross-Origin Resource Sharing acts like a security system in web browsers. It manages how one website requests and receives data from another.

When a web page tries to fetch data from a different domain CORS steps in to decide if it’s allowed. It works by servers specifying in advance which websites are allowed to access their resources through special rules in HTTP headers like “Access-Control-Allow-Origin”.

The Access-Control-Request-Method header is used in the preflight request to tell the server what HTTP method will be used in the actual request.

Think of CORS as a permission check: if the requesting website is listed the browser allows it. CORS also allows servers to set more granular rules like what type of requests are allowed or if custom data can be shared. This prevents unauthorized access and secures web apps.

In simple terms Web.dev says “Enabling CORS lets the server tell the browser it’s allowed to use an additional origin”.

According to BuiltWith stats around 2000 sites out of top 1 million use this feature.

Cross-Origin Resource Sharing (CORS) security

Using CORS which allows different websites to share information can be safe if done correctly. CORS is like a security rule in web browsers that limits how websites can ask for and use data from other places. You need to enable CORS if you have a website that needs to use resources from places that are not its server but you also need to set up CORS correctly to keep things safe.

If CORS is not set up correctly it can expose the server to risks by allowing requests from places that shouldn’t be allowed. To make it safe you need to control and limit where requests can come from and use other CORS settings. The Access-Control-Request-Headers header is used in the preflight request to tell the server what custom headers will be sent with the actual request.

So the short answer is yes turning on CORS can be safe but don’t forget to do it correctly and set it up right to avoid any security issues.

What’s the difference between CORS and CSP?

CORS (Cross-Origin Resource Sharing) and CSP (Content Security Policy) are different because they do different things for web security. CORS allows or blocks requests for things like images or scripts between different websites in the browser. It decides how the browser should handle requests between sites to prevent security issues.

On the other hand CSP deals with reducing risks from attacks like Cross-Site Scripting (XSS). It does this by defining from where the browser can get resources like scripts or images. CSP makes a rule that tells the browser what sources are allowed and what sources are not and stops the execution of malicious codes.

In simple terms CORS manages requests between websites, while CSP controls from where the browser gets its resources and stops the execution of malicious code. Both are important to secure web apps.

Types of CORS Requests

CORS requests can be categorized into two primary types: simple requests and preflight requests.

Cross-Origin Resource Sharing directives and examples

CORS directives are instructions from a web server to a web browser about how to handle requests from other websites. These instructions are sent through special headers in the server’s response. Here are the main Cross-Origin Resource Sharing directives and let’s see a few examples:

Access-Control-Allow-Origin: specifies which websites can use the resource. Examples:

Allow one specific website:

Access-Control-Allow-Origin: https://example.com

Allow any website:

Access-Control-Allow-Origin: *

Access-Control-Allow-Methods: lists which actions (like GET or POST) are allowed.
Example:

Access-Control-Allow-Methods: GET, POST, OPTIONS

Access-Control-Allow-Headers: this one lists which types of information can be sent with the request.
Example:

Access-Control-Allow-Headers: Content-Type, Authorization

Access-Control-Allow-Credentials: tells whether the browser can send things like cookies with the request.
Example:

Access-Control-Allow-Credentials: true

Access-Control-Expose-Headers: it lists which response headers the browser can see.
Example:

Access-Control-Expose-Headers: Content-Length, X-My-Custom-Header

Access-Control-Max-Age: determines for how long the browser can remember the permissions without asking again.
Example:

Access-Control-Max-Age: 86400

How to configure Cross-Origin Resource Sharing

Let’s see how to Cross-Origin Resource Sharing (CORS) in popular web servers like Apache and Nginx.

Enabling CORS in Apache

Setting up Cross-Origin Resource Sharing in Apache is pretty easy.

Start by opening your site’s config file under Apache, this may be an individual .conf file or the Apache main .conf file.

Look for the VirtualHost section and add CORS settings right there:

Header set Access-Control-Allow-Origin "*"
Header always set Access-Control-Allow-Methods "POST, GET, OPTIONS, DELETE, PUT"
Header always set Access-Control-Max-Age "1000"
Header always set Access-Control-Allow-Headers "X-Requested-With, Content-Type, Origin, Authorization, Accept, Client-Security-Token, Accept-Encoding"

The settings above are just an example, remember to tweak them according to your needs.

Restart Apache to apply the new settings:

systemctl restart apache2

If you’re using .htaccess you can set the rules the same way, and you won’t need to restart Apache to apply them.

How to enable Cross-Origin Resource Sharing

Let’s see how to enable Cross-Origin Resource Sharing (CORS) in popular web servers like Apache, Nginx, and IIS.

Setting up CORS in Nginx

Setting up CORS in Nginx is very straightforward.

Start by opening your site’s config file under Nginx, it’s located usually in your Nginx’s sites-available directory or conf.d directory.

Look for the Server section and add CORS rules right there:

add_header 'Access-Control-Allow-Origin' '*';
add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';
add_header 'Access-Control-Expose-Headers' 'Content-Length,Content-Range';
add_header 'Access-Control-Allow-Credentials' 'true';

Our settings above are just an example, remember to tweak them according to your needs.

Test your new Nginx config and restart it to apply the new settings:

nginx -t
systemctl restart nginx

Configuring CORS on IIS

Setting up the CORS header on IIS can be done quickly and easily.

1. Open the IIS Manager and select the site where you wish to configure the CORS header.
2. Open HTTP Response Headers and click on Add.
3. Here are the headers you may need to add, depending on your requirements. Remember that these are examples.
4. Allow Origins:
   • Name: Access-Control-Allow-Origin
   • Value: add the allowed origin(s), for instance https://example.com or use * to allow all origins (not recommended for production).
5. Allow Methods:
   • Name: Access-Control-Allow-Methods
   • Value: GET, POST, OPTIONS
6. Allow Credentials:
   • Name: Access-Control-Allow-Credentials
   • Value: true
7. Save the changes to apply the new header.

Testing Cross-Origin Resource Sharing

Testing your current Cross-Origin Resource Sharing settings is pretty easy, just follow our steps:

1. Access our web security scanner.
2. Input your domain in the scan box.
3. Click the two boxes below, which are called ‘Clear cache’ and ‘Follow redirects’.
4. Now hit the Scan button.
5. Scroll down and look for the section named ‘HTTP Security Headers’, and check your ‘Cross-Origin Resource Sharing’ test results: if you get a ‘Passed’ in green then you’re good to go, but if you get a ‘Failed’ in red then you need to update your current settings.

Cross-Origin Resource Sharing (CORS) FAQ

Do I need to enable CORS?

No, but you’ll need it if you want to allow web pages from one domain to access resources from another domain. If you want to know if your site has it enabled, you can check using our web misconfiguration scanner, as above.

Is Cross-Origin Resource Sharing a vulnerability?

No, CORS is a security feature. It protects websites from malicious cross-origin requests by allowing or blocking access to resources based on the server’s configuration. Without CORS, browsers would block cross-origin requests by default.

Is Cross-Origin Resource Sharing still needed?

Yes, CORS is still needed. As websites grow and rely on many services, enabling secure cross-origin communication is a must to have a smooth user experience and data security.

Does Cross-Origin Resource Sharing protect the server or the client?

CORS protects the server. It allows only authorized domains to access resources on a server, preventing security threats. While CORS doesn’t protect the client directly, it helps to a safer web by controlling cross-origin resource requests.

Can Cross-Origin Resource Sharing be configured per resource?

Yes, CORS can be configured per resource. Servers can specify which resources are accessible to requests from different origins by setting the CORS headers. This gives great control over cross-origin access and allows you to expose only the necessary resources and keep others protected.

What are the challenges of Cross-Origin Resource Sharing?

Implementing CORS is complex and can lead to security risks if not done correctly. Some of the challenges are misconfigurations that can lead to unintended access, testing across different browsers and environments and performance issues due to extra HTTP requests and header processing.

Conclusion

Cross-Origin Resource Sharing (CORS) is a security feature that controls resource requests between different domains and prevents unauthorized access. When a browser makes a request to a domain other than the current page, CORS headers are sent to specify if the request should be allowed or denied. Configuring CORS headers correctly is very important to have secure and smooth interactions across different domains.

It works by servers specifying in advance which websites are allowed to access their resources through special rules in HTTP headers like “Access-Control-Allow-Origin”. Enabling CORS is safe if done correctly but misconfiguring it can expose the server to risks by allowing unauthorized access.