What is CORS? Exploring the Cross-Origin Resource Sharing Policy and Its Impact

What is CORS and Why is It Important?

Cross-Origin Resource Sharing (CORS) is a security protocol that enables web servers to specify which external origins can access their resources. CORS was designed to improve the Same-Origin Policy (SOP), a security measure used by browsers to prevent unauthorized access to sensitive data from other domains.

In this article, we’ll explore the Same-Origin Policy, how CORS extends its capabilities, and the importance of the preflight request in ensuring secure cross-origin communication.

Understanding the Same-Origin Policy (SOP)

The Same-Origin Policy (SOP) is a browser security feature that restricts how resources can be accessed across different web applications. This policy ensures that the resource being accessed must come from the same origin as the web application making the request.

For two origins to be considered the same, they must share the same host, scheme (protocol), and port. Let’s consider this URL as an example: https://app.optimizory.com:8080.

• Scheme: HTTPS
• Host: app.optimizory.com (with "app" being a subdomain of optimizory.com)
• Port: 8080

In this case, the port number is included for reference, as it can vary depending on the server configuration. It's important to note that an origin with an "http" scheme is different from an otherwise identical origin with an "https" scheme.

However, https://app.optimizory.com is considered the same origin as https://app.optimizory.com/features because they share the same scheme, host, and port.

While the Same-Origin Policy (SOP) restricts cross-origin access to many resources, it is more flexible with certain types of content. These resources can be accessed or embedded from different origins without strict restrictions:

• Images: Websites can embed images from any origin without limitations. These images can be freely loaded and displayed across different domains.
• CSS Stylesheets: External CSS files can be loaded from various origins using the <link> tag in HTML or the @import rule within another stylesheet.
• Scripts: JavaScript files can be loaded and executed from any origin. However, they are subject to SOP restrictions when interacting with DOM elements. While scripts can run from different origins, they are prohibited from making cross-origin API calls or manipulating content outside their origin.
• Media Files: Audio and video files, like images, can be embedded from any origin using the <audio> and <video> tags, allowing content to be played across different domains.
• Iframes: Content from other origins can be embedded using iframes. However, SOP ensures that the content inside an iframe is isolated from the parent page, preventing direct access to the parent page’s resources. Communication between the iframe and the parent page is only possible through defined JavaScript interfaces.

How Does CORS Work?

The Same-Origin Policy (SOP), enforced by browsers, restricts access to certain resources from different origins for security reasons. However, Cross-Origin Resource Sharing (CORS) allows servers to bypass these restrictions by specifying which origins are allowed to access their resources. CORS works by utilizing specific HTTP headers in requests and responses to communicate with the server and grant permission for cross-origin access. In the next section we will talk about what is a preflight request.

Different Types Of CORS Requests

There are two primary types of CORS requests: simple requests and preflight requests.

What Is a Simple Request?

Simple requests are straightforward and sent as part of the main HTTP request. To qualify as a simple request, the following conditions must be met:

The request must use one of the following HTTP methods: GET, HEAD, or POST.

• Request headers must be limited to “simple headers,” which browsers automatically deem safe. These include headers like Accept, Accept-Language, Content-Language, and Content-Type.
• If the POST method is used, the Content-Type header must have one of the following values: application/x-www-form-urlencoded, multipart/form-data, or text/plain.
• If these criteria are satisfied, the request is sent directly to the server, and the server responds based on its CORS policy.

What Is a Preflight Request?

Preflight requests are used for more complex cross-origin requests, where additional verification is needed. The browser sends a preflight request to ensure the server is willing to allow a CORS request. These preflight checks occur in the following scenarios:

• When the request method is not one of the simple methods (GET, HEAD, or POST). This usually involves methods like PUT or DELETE.
• When the request headers include content types other than application/x-www-form-urlencoded, multipart/form-data, or text/plain for POST requests.
• The browser sends a preflight request using the OPTIONS HTTP method to ask the server for permission before sending the actual request that might modify data.

Preflight Request Headers

When making a preflight request, the browser includes specific headers to inform the server about the upcoming request:

• Access-Control-Request-Method: This header specifies the HTTP method (e.g., PUT, DELETE) that the browser intends to use for the actual request.
• Access-Control-Request-Headers: This header lists any custom or additional headers that the browser will send with the actual request.

If the server allows the cross-origin request by responding favorably to the preflight request, the browser proceeds with the actual request. If the preflight request fails, the browser will block the request, resulting in a CORS error.

CORS Response Headers

When a server responds to a CORS request, it uses specific HTTP headers to communicate with the browser and control access. These headers inform the browser about which cross-origin requests are permitted and how they should be handled. Here’s a breakdown of the key CORS response headers:

1. Access-Control-Allow-Origin: This header specifies which origins are allowed to access the server's resources. It can either be set to a specific origin (e.g., https://postman.com) or use a wildcard (*) to allow any origin.
2. Access-Control-Allow-Credentials: This boolean header indicates whether the browser should include credentials (such as cookies or HTTP authentication) with the cross-origin request. If set to false, credentials will not be sent. For preflight requests, if this header is false, the browser will exclude credentials from the actual request. For simple requests, setting this header to false prevents credentials from being sent.
3. Access-Control-Allow-Methods: This header is used in responses to preflight requests to specify which HTTP methods (e.g., GET, POST, PUT, DELETE) are allowed for cross-origin requests.
4. Access-Control-Allow-Headers: This header, found in responses to preflight requests, lists the headers that are permitted in the actual cross-origin request.
5. Access-Control-Max-Age: This header defines the maximum time (in seconds) that the browser can cache the results of a preflight request. Reusing cached responses helps reduce the number of preflight requests.
6. Access-Control-Expose-Headers: This header indicates which response headers can be exposed to the browser and accessed by client-side JavaScript. Headers not included in this list will be hidden from client-side code.

Status Codes for CORS Responses

A successful response to a CORS request can include any HTTP status code, as long as it includes the appropriate CORS headers. However, a successful response to a preflight request must return a status code of either 200 OK or 204 No Content to confirm that the server allows the cross-origin request.

These headers and status codes work together to ensure that cross-origin interactions are secure and adhere to the server’s access policies.

Benefits of Working with CORS

Implementing Cross-Origin Resource Sharing (CORS) offers several advantages that enhance both security and flexibility in web applications. Here are the key benefits of using CORS:

1. Improved API Security: CORS strengthens security by controlling which origins can access your server's resources. It mitigates the risk of unauthorized cross-origin requests and helps protect against attacks like Cross-Site Request Forgery (CSRF) and unauthorized data access. By requiring explicit permission through CORS headers, it ensures that only approved origins can interact with your APIs.
2. Secure Cross-Origin Authentication: CORS facilitates secure cross-origin authentication by allowing the transmission of credentials, such as cookies or authentication tokens, in requests. This is particularly useful for Single Sign-On (SSO) and other authentication systems that require secure cross-origin interactions.
3. Standardization Across Browsers: CORS is a standardized protocol supported by all major web browsers. This consistency ensures a uniform approach to handling cross-origin requests, providing reliable and predictable behavior across different browser environments.
4. Enhanced API Integration: CORS is crucial for integrating web applications with external APIs. It enables developers to access and utilize third-party services and functionalities within their own applications, fostering greater interoperability and enhancing the capabilities of their services.

Best Practices for Implementing Cross-Origin Resource Sharing Policy

When configuring a Cross-Origin Resource Sharing (CORS) policy, it is crucial to adhere to best practices to ensure both security and functionality. Here are some key guidelines to follow:

1. Avoid Cache Poisoning: Manage the Access-Control-Max-Age header carefully to prevent cache poisoning. If set for too long, cached responses may use outdated permissions, posing security risks. A moderate duration, around five seconds, is recommended to balance performance with security.
2. Specify Origins Explicitly: Avoid using wildcards (*) in the Access-Control-Allow-Origin header. Instead, explicitly list the origins that are allowed to access your resources. This practice minimizes the risk of unauthorized access. Additionally, define the permitted methods and headers explicitly using Access-Control-Allow-Methods and Access-Control-Allow-Headers headers.
3. Include All Necessary CORS Headers: Ensure your server response includes all essential CORS headers. Omitting crucial headers can lead to security vulnerabilities. For instance, if the Access-Control-Allow-Credentials header is missing or incorrectly configured, it can result in improper handling of credentials, leading to potential data leaks or unauthorized access.
4. Document Your CORS Policy: Clearly document your Cross-Origin Resource Sharing policy and provide this information to developers integrating with your API. Proper documentation facilitates better integration and adherence to correct practices, enhancing both developer experience and trust.
5. Securely Handle Credentials: CORS policies do not include credentials (such as cookies or authentication tokens) by default. If your application requires credentials, set the Access-Control-Allow-Credentials header to true. Ensure that your server is equipped to validate and securely manage these credentials to prevent unauthorized access.

Implementing a robust Cross-Origin Resource Sharing policy by following these best practices helps in maintaining secure and effective cross-origin interactions, safeguarding your application from potential vulnerabilities.