Facebook Google Plus Twitter LinkedIn YouTube RSS Menu Search Resource - BlogResource - WebinarResource - ReportResource - Eventicons_066 icons_067icons_068icons_069icons_070

Tenable Blog

  • Twitter
  • Facebook
  • LinkedIn

Understanding Cross-Origin Resource Sharing Vulnerabilities

Understanding Cross-Origin Resource Sharing Vulnerabilities

To avoid exposure to a variety of web application vulnerabilities, specific security considerations must be made when implementing Cross-Origin Resource Sharing

Today’s modern web applications rely heavily on JavaScript to be dynamic, and ensure the best experience for end-users. Providing content and data to the users often requires interactions with other web applications, which include cross-domain requests and an additional configuration step on the application side known as a Cross-Origin Resource Sharing (CORS) policy.

In this post, we will explain how a misconfiguration of a CORS policy can make your web application vulnerable, and how the Tenable.io Web Application Scanner (WAS) can help you identify these vulnerabilities.

CORS “Origins”

The web application security model implemented by web browsers is built using multiple concepts, with one of the most important being the Same-Origin Policy (SOP). The purpose of the SOP is to restrict interactions between scripts loaded on the origin and the resources hosted on other origins. An origin consists of a combination of the protocol, hostname, and port.

CORS is an extension to the SOP defined by the World Wide Web Consortium (W3C), which enables web applications to add the origins allowed to read responses to cross-domain requests to an allowlist and enforce it at the client browser level.

The implementation of the CORS standard relies on the introduction of multiple Hypertext Transfer Protocol (HTTP) headers used in the communication between the client and the target application.

In the simplest example of implementing CORS, when a web browser loads a web page requesting cross-domain resources, the Origin HTTP header is added in the request to the external resource. The application’s response will then include the Access-Control-Allow-Origin header to define which origins are authorized to read the application responses. In certain instances, the Access-Control-Allow-Credentials header may also be part of the response to specify whether or not the calling script is allowed to ask the browser to include credentials in the cross-domain request, such as session cookies, authorization headers, or TLS client certificates. Upon receiving the cross-domain target application’s response, the client browser checks if the origin is granted to read the response or blocks it according to the configured CORS policy.

Complex requests like the ones using specific HTTP methods, such as PUT or DELETE, or custom HTTP headers will trigger an additional request called a preflight request. The preflight request is first issued with an OPTIONS request, which is designed to check if the target application has CORS enabled and supports the different options sent in the request.

In this situation, the application response contains additional headers like the Access-Control-Allow-Methods HTTP header, which specifies the HTTP methods allowed when using cross-domains requests.

Once the preflight request is complete, the real request is sent to the target application.

Common vulnerabilities

Because CORS is an access control mechanism, it can be misconfigured, thereby enabling an attacker to bypass it and make the client browser act as a proxy between a malicious website and the target web application. Most of the time the related security risk is underestimated and becomes more important when the web application allows authenticated requests.

One of the most common misconfigurations is the value defined in the Access-Control-Allow-Origin header sent back by the application. The list below describes some of the most common errors made when defining a CORS policy

  • When using a wildcard with a value of an asterisk (*) in the Access-Control-Allow-Origin header, any origin is allowed to read responses from cross-domains requests. The CORS specification includes a particular security check for this scenario that prevents the Access-Control-Allow-Credentials header to be set to “true in this case.
  • Using a “null” value and assuming this will disable cross-domain request capabilities. On the contrary, this configuration has the same impact as using a wildcard. Web browsers automatically use the null origin in some circumstances, such as after a CORS request has been redirected by the target resource, or when this request has been sent from a specific resource type (for example, from an iframe, or using a local file).
  • Building dynamic Access-Control-Allow-Origin with improper server-side validation. The specification only defines a single origin in the Access-Control-Allow-Origin response header. When multiple origins need to be trusted, developers have to deal with dynamic validation of the origin by using regular expressions based on the target application domain.

In the case of misconfiguration, the regular expression can, for example, implicitly authorize the application derived hostname. In other situations, the Origin header sent by the web browser is simply reflected, leading to the same impact as using a wildcard value. This is a common practice to circumvent the control that prevents using both the wildcard allowlist and the credentials.

  • “Trusting” public third party services. Hosting infrastructures like Cloud providers (storage buckets), content delivery networks (CDNs), or code hosting services are sometimes allowed in the CORS policy. By definition, these public services are available for a potential attacker who can leverage them to host malicious JavaScript code and issue cross-domain requests to the vulnerable application.

Exploitation and security risks

With some background on the different vulnerabilities associated with CORS misconfigurations, let’s have a look at the security risks and impacts.

The common exploitation scenarios can be described by the following steps:

  1. An attacker sets up a malicious website hosting JavaScript code, which aims to retrieve data from a vulnerable web application.
  2. The attacker entices the victim to visit the website using phishing or an unvalidated redirection in the target application.
  3. The JavaScript code is then loaded in the victim browser and performs silent cross-domain authenticated requests to the target application to steal data and store it.

Although the risk increases when the CORS policy allows the usage of requests with credentials, there can be situations where a simple origin that is not properly validated can have a big impact. For example, intranet web applications sometimes do not follow a standard security design and may allow any user located on the corporate network to reach its internal content without authentication. If the application's CORS policy is not correctly enforced and the victim user visits the malicious website, this could result in an information leak.

Information leakage is a basic exploitation case of CORS vulnerabilities. However, attackers often leverage these issues to perform advanced attack scenarios, which can lead to the takeover of application user accounts or the execution of arbitrary modifications in the target application on behalf of the victim user. Earlier this year, Chris Lyne, senior research engineer on Tenable’s Zero Day Research Team, disclosed a vulnerability in Plex Media Server due to a weak CORS policy and described the related risks for the Plex application users.

Leverage Tenable.io WAS to detect CORS issues

Tenable.io WAS helps you identify CORS issues with multiple plugins designed to audit a web application during a scan. The main purpose is to be able to:

Once detection of a CORS issue occurs, Tenable.io WAS provides the relevant information helping identify the configuration to fix, as well as the related guidance to remediate the issue.

Generally speaking, CORS vulnerabilities are configuration errors and can be easily fixed with the following principles:

  • If the application does not require cross-origin requests, the only action is to check that no policy is set.
  • Always ensure that the Access-Control-Allow-Origin header allows the most specific origins and is not over permissive. A wildcard configuration should only be defined when the whole content of the application is made to be public.
  • Restrict the Access-Control-Allow-Methods header to match what the application needs.
  • Consider using real “trusted” origins. By default, public Cloud providers or services like GitHub Pages should not be in your trust zone when dealing with CORS.
  • Set the Access-Control-Allow-Credentials header to true only when required and after having validated that the Access-Control-Allow-Origin header is properly set.

Finally, it is important to note that a CORS policy is not a security feature by itself and still requires common application security best practices.

Get more information

Related Articles

Are You Vulnerable to the Latest Exploits?

Enter your email to receive the latest cyber exposure alerts in your inbox.

Try for Free Buy Now
Tenable.io FREE FOR 30 DAYS

Enjoy full access to a modern, cloud-based vulnerability management platform that enables you to see and track all of your assets with unmatched accuracy. Sign up now.

Tenable.io BUY

Enjoy full access to a modern, cloud-based vulnerability management platform that enables you to see and track all of your assets with unmatched accuracy. Purchase your annual subscription today.

65 assets

Choose Your Subscription Option:

Buy Now
Try for Free Buy Now

Try Nessus Professional Free


Nessus® is the most comprehensive vulnerability scanner on the market today. Nessus Professional will help automate the vulnerability scanning process, save time in your compliance cycles and allow you to engage your IT team.

Buy Nessus Professional

Nessus® is the most comprehensive vulnerability scanner on the market today. Nessus Professional will help automate the vulnerability scanning process, save time in your compliance cycles and allow you to engage your IT team.

Buy a multi-year license and save. Add Advanced Support for access to phone, community and chat support 24 hours a day, 365 days a year. Full details here.

Try for Free Buy Now

Try Tenable.io Web Application Scanning


Enjoy full access to our latest web application scanning offering designed for modern applications as part of the Tenable.io platform. Safely scan your entire online portfolio for vulnerabilities with a high degree of accuracy without heavy manual effort or disruption to critical web applications. Sign up now.

Buy Tenable.io Web Application Scanning

Enjoy full access to a modern, cloud-based vulnerability management platform that enables you to see and track all of your assets with unmatched accuracy. Purchase your annual subscription today.



Buy Now

Try for Free Contact Sales

Try Tenable.io Container Security


Enjoy full access to the only container security offering integrated into a vulnerability management platform. Monitor container images for vulnerabilities, malware and policy violations. Integrate with continuous integration and continuous deployment (CI/CD) systems to support DevOps practices, strengthen security and support enterprise policy compliance.

Buy Tenable.io Container Security

Tenable.io Container Security seamlessly and securely enables DevOps processes by providing visibility into the security of container images – including vulnerabilities, malware and policy violations – through integration with the build process.

Try for Free Contact Sales

Try Tenable Lumin


Visualize and explore your Cyber Exposure, track risk reduction over time and benchmark against your peers with Tenable Lumin.

Buy Tenable Lumin

Contact a Sales Representative to see how Lumin can help you gain insight across your entire organization and manage cyber risk.