DEV Community

Cover image for Understanding CORS Misconfiguration
Nathan
Nathan

Posted on

7 6

Understanding CORS Misconfiguration

In this article I will explain what cross-origin sharing is, give some examples and real case scenario and finally how to prevent from this misconfiguration.

CORS Explained

Cross origin sharing is a browser mechanism which control
to access resources from another domain. This can be used to share resources between different domains, or to allow a web page to access resources from a domain that is not the same as the domain from which the web page was served.
CORS was originally create to add more flexibility yo same-origin policy mechanism (SOP). SOP prevent website to attacking each other by implement a strict policy which describe how website can reach each other.
The cross-origin resource sharing uses a suite of HTTP headers that define trusts web domains origins and associated properties.

Allow an Origin

In order to allow a specific origin the header 'Allow-Control-Origin" has to be included in the response from a website which receive a CORS request.
The browser compare the value of the header with the requesting website's origin and allow access if they correspond.
Concert example :
A website wants to use a resource from a remote host.

GET /data HTTP/1.1
Host: remote-website.com
Origin : https://test-website.com
Enter fullscreen mode Exit fullscreen mode

The server of the requesting website (remote-website.com) return the following response:

HTTP/1.1 200 OK
...
Access-Control-Allow-Origin: https://test-website.com
Enter fullscreen mode Exit fullscreen mode

The browser will compare the response and in this case the browser will permit because the origins match.

In the case where there is no restriction the server will return wildcard into the server header.

Allow Credentials

Cross-origin resource requests are sent without credentials such as cookies and the Authorization header by default.
When credentials are supplied to the cross-domain server, the CORS Access-Control-Allow-Credentials header is set to true, allowing reading of the response. Then the browser will permit the requesting website to get the response.

Access-Control-Allow-Credentials: true

Security Issues

Unfortunately give flexibility often generate security issues.
If a website's CORS is poorly configured it is can potentially lead to cross-domain attacks.
Take a bank virtual as example, suppose that an attacker stole user's cookies the attacker will send the following request:

GET /account-details HTTP/1.1
Host: virutal-bank.com
Origin: https://malicious-website.com
Cookie: sessionid=..
Enter fullscreen mode Exit fullscreen mode

Then the bank's server will respond :

HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://malicious-website.com
Access-Control-Allow-Credentials: true
Enter fullscreen mode Exit fullscreen mode

The response's server allows the malicious attacker to send cross request, and that the request can include cookies .
In this case because the App reflects arbirtrary subdomain from the origin header , theoretically every domains can access ressources from this vulnerable bank's website.
In result with a bad CORS configuration an attacker could read sensitive bank's information.

Does CORS protect against CSRF?

CORS does not specifically protect against CSRF, but it does add an extra layer of security. If an attacker does manage to exploit a CSRF vulnerability, they will only be able to access resources that are allowed by the CORS policy.

How to protect against CORS Misconfiguration?

Misconfigurations are the primary cause of CORS vulnerabilities.
Proper setting is critical to preventing these threats.
The sections that follow outline several viable CORS defenses.

If a web resource includes sensitive information, make sure the origin is appropriately stated in the Access-Control-Allow-Origin header.

Allow only trustworthy websites access to the resource.
It is especially dangerous to dynamically reflect origins from cross-origin requests without validation.

Use the Access-Control-Allow-Origin: null header as little as possible.
Cross-origin resource calls from internal documents and sandboxed requests can have a null origin specified.
For both private and public servers, CORS headers should be appropriately established in terms of trustworthy origins.

Internal networks should be free of wildcards.
When internal browsers may access untrusted external sites, relying on network setup alone to safeguard internal resources is insufficient.

Check your API security at www.blstsecurity.com.

Billboard image

Synthetic monitoring. Built for developers.

Join Vercel, Render, and thousands of other teams that trust Checkly to streamline monitor creation and configuration with Monitoring as Code.

Start Monitoring

Top comments (0)

A Workflow Copilot. Tailored to You.

Pieces.app image

Our desktop app, with its intelligent copilot, streamlines coding by generating snippets, extracting code from screenshots, and accelerating problem-solving.

Read the docs

👋 Kindness is contagious

Dive into an ocean of knowledge with this thought-provoking post, revered deeply within the supportive DEV Community. Developers of all levels are welcome to join and enhance our collective intelligence.

Saying a simple "thank you" can brighten someone's day. Share your gratitude in the comments below!

On DEV, sharing ideas eases our path and fortifies our community connections. Found this helpful? Sending a quick thanks to the author can be profoundly valued.

Okay