Access Control Allow Origin

The HTTP Access-Control-Allow-Origin response header specifies whether a server’s response can be shared with requesting code from a particular origin. This header is a fundamental part of implementing Cross-Origin Resource Sharing (CORS), which allows servers to control which origins can access their resources, enhancing web security and enabling controlled cross-site interactions.

Note: Including this header in server responses is essential for enabling cross-origin requests safely. Without it, browsers may block frontend applications from accessing resources hosted on different domains.

Header type	Response header
Forbidden request header	No

Syntax

Request headers are used to specify the origins that are allowed to access resources on a server. The “Access-Control-Allow-Origin” header controls which origins are permitted. The following are common examples:

Access-Control-Allow-Origin: *
Access-Control-Allow-Origin: <origin>
Access-Control-Allow-Origin: null

Directives

* (wildcard)

The server permits access to the resource from any origin. For requests without credentials, the literal value * can be used as a wildcard. Using the wildcard with credentials results in an error.

<origin>

This specifies a single origin. If the server supports multiple clients from different origins, it should return the origin of the specific client making the request.

null

This designates the origin as “null”.

Note:
The value null is generally discouraged. It might appear safe to set the Access-Control-Allow-Origin header to “null”, but such situations often arise with resources utilizing non-hierarchical schemes like data: or file: and sandboxed documents, which serialize their origin as null. Many browsers will permit scripts from such documents to access responses with Access-Control-Allow-Origin: null. Additionally, any origin can create a malicious document with a null origin. Therefore, the use of the null value should be avoided when configuring these headers.

Examples

A response that instructs the browser to permit code from any origin to access a resource will include the following:

Access-Control-Allow-Origin: *

A response that allows requesting code from the specific origin https://developer.mozilla.org to access a resource will include:

Access-Control-Allow-Origin: https://developer.mozilla.org

To restrict the Access-Control-Allow-Origin value to a predefined set of origins, the server must check the Origin request header, compare it against a list of permitted origins, and if the origin is allowed, set the Access-Control-Allow-Origin response header to match the Origin value.

Note: When the server responds with a specific Access-Control-Allow-Origin value instead of the wildcard *, it should also include a Vary header with the value Origin. This informs browsers that the response may vary depending on the Origin request header value.

Example of such headers:

Access-Control-Allow-Origin: https://developer.mozilla.org
Vary: Origin

Same-Origin Policy and Caching

When the server responds with an Access-Control-Allow-Origin header specifying a particular origin, it should also include a Vary response header with the value Origin. Doing so indicates to browsers that the response content may differ based on the Origin header, enabling proper caching behavior and ensuring content is served correctly for requests from different origins.

How to Modify Header using Requestly

Requestly is a powerful Chrome extension that allows you to modify HTTP headers, including the Access-Control-Allow-Origin header. This is particularly helpful for testing how your web application handles cross-origin resource sharing (CORS) policies during development or troubleshooting. Steps to Modify the Access-Control-Allow-Origin Header:

1. Install and open the Requestly Chrome extension. You can find it on the Chrome Web Store.
2. Create a new rule: Click on “Create Rule” and choose “Modify Headers” from the list of available rule types.
3. Add a new header modification:
   • Under “Action”, select “Add” or “Override”.
   • In the “Header Name” field, enter Access-Control-Allow-Origin.
   • In the “Header Value” field, enter the desired origin value (e.g., * or https://example.com).
4. Set the URL condition: Specify the URL or pattern where this header change should apply (e.g., https://your-api.com/\*).
5. Save the rule.

Once set up, Requestly will inject the Access-Control-Allow-Origin header into all matching requests, allowing you to control which origins are permitted to access your resources during testing. Modifying the Access-Control-Allow-Origin header helps you test and debug CORS-related issues by simulating different cross-origin permissions. This can ensure your application works smoothly when accessed from various domains.