TPM Tech Talk: What is Cross-Origin Resource Sharing (CORS)?

Cross-Origin Resource Sharing (CORS) is a web technology that allows browsers to access resources from different domains in a controlled and secure way. CORS is useful for web applications that need to interact with external services or APIs, such as fetching data, loading fonts, or displaying images. In this article, we will explain how CORS works, what are the benefits and risks of using it, and how to implement it correctly on your web server.

How CORS works

CORS is based on a set of HTTP headers that are exchanged between the browser and the server hosting the cross-origin resource. The browser initiates a CORS request by sending an Origin header that indicates the origin of the web page that is requesting the resource. The server responds with an Access-Control-Allow-Origin header that specifies which origins are allowed to access the resource. If the origin of the web page matches the value of the header, the browser grants access to the resource. Otherwise, the browser blocks the request and throws an error.

There are two types of CORS requests: simple and preflighted. Simple requests are those that use the GET, HEAD, or POST methods, and have no custom headers or content types. Preflighted requests are those that use other methods (such as PUT, DELETE, or PATCH), or have custom headers or content types (such as application/json or text/xml). Preflighted requests require an extra step before the actual request, where the browser sends an OPTIONS request to the server with the Access-Control-Request-Method and Access-Control-Request-Headers headers, asking for permission to perform the actual request. The server responds with the Access-Control-Allow-Methods and Access-Control-Allow-Headers headers, indicating which methods and headers are allowed. If the actual request matches the preflight response, the browser proceeds with the request. Otherwise, the browser aborts the request and throws an error.

Benefits and risks of CORS

CORS is a powerful feature that enables web applications to communicate with external services or APIs, without relying on server-side proxies or JSONP techniques. This can improve the performance, scalability, and security of web applications, as well as provide a better user experience. However, CORS also introduces some potential risks, especially if it is not configured or implemented correctly. Some of the common CORS vulnerabilities are:

• Server-generated Access-Control-Allow-Origin header from client-specified Origin header: Some servers may dynamically generate the Access-Control-Allow-Origin header based on the value of the Origin header sent by the browser, without validating it. This can allow any origin to access the resource, which can lead to information disclosure, CSRF, or XSS attacks.
• Wildcard Access-Control-Allow-Origin header: Some servers may use a wildcard (*) as the value of the Access-Control-Allow-Origin header, which means that any origin can access the resource. This can also lead to information disclosure, CSRF, or XSS attacks, especially if the resource contains sensitive or user-specific data, or performs state-changing actions.
• Misconfigured Access-Control-Allow-Credentials header: Some servers may use the Access-Control-Allow-Credentials header to indicate whether the browser should send cookies or other credentials with the request. If this header is set to true, and the Access-Control-Allow-Origin header is set to a wildcard or a specific origin, the browser will send the credentials with the request, which can allow an attacker to steal or manipulate the user’s session or data.

How to implement CORS correctly

To implement CORS correctly on your web server, you should follow these best practices:

• Use a whitelist of trusted origins, and validate the Origin header against it. Do not use a wildcard or a dynamic value for the Access-Control-Allow-Origin header.
• Use the Vary header to indicate that the response varies based on the Origin header. This can prevent caching issues and ensure that the correct response is delivered to the browser.
• Use the Access-Control-Allow-Credentials header only if you need to send cookies or other credentials with the request, and only if the Access-Control-Allow-Origin header is set to a specific origin. Do not use a wildcard or a dynamic value for the Access-Control-Allow-Credentials header.
• Use the Access-Control-Expose-Headers header to specify which response headers are available to the browser. By default, the browser can only access the Cache-Control, Content-Language, Content-Type, Expires, Last-Modified, and Pragma headers. If you need to expose other headers, such as X-Requested-With or Authorization, you need to list them in the Access-Control-Expose-Headers header.
• Use the Access-Control-Max-Age header to specify how long the browser can cache the preflight response. This can reduce the number of preflight requests and improve the performance of your web application.

CORS is a useful and powerful web technology that can enable cross-origin communication between web applications and external services or APIs. However, it also requires careful configuration and implementation to avoid security risks and vulnerabilities. By following the best practices described in this article, you can implement CORS correctly on your web server and enjoy the benefits of CORS without compromising the security of your web application.

Source: Conversation with Bing, 12/30/2023
(1) Cross-Origin Resource Sharing (CORS) – HTTP | MDN. https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS.
(2) Cross-origin resource sharing (CORS) – PortSwigger. https://portswigger.net/web-security/cors.
(3) Cross-origin resource sharing – Wikipedia. https://en.wikipedia.org/wiki/Cross-origin_resource_sharing.
(4) Cross-Origin Resource Sharing – IBM. https://www.ibm.com/docs/en/integration-bus/10.0?topic=overview-cross-origin-resource-sharing.
(5) undefined. https://domain-a.com.
(6) undefined. https://domain-b.com/data.json.