CORS HTTP header

Learn more about how the CORS HTTP header policy works on the Digibee Integration Platform.

CORS stands for Cross-Origin Resource Sharing. It’s an HTTP header-based mechanism that allows a server to specify origins other than its own, such as domain, scheme, or port, from which a browser should allow resources to be loaded.

In the Digibee Integration Platform, the CORS HTTP header policy allows you to specify headers to check the cross-origin resource with the server hosting it to see if the request is allowed. You can also define different key-value pairs for headers in production and other environments.

How to configure a CORS HTTP header policy

Follow these steps to configure a CORS HTTP header policy:

1. On the Platform home page, click Administration in the upper right corner.

2. Click Policies.

3. Click the Transformation tab.

4. Open the CORS HTTP header policy. You will see a different configuration for each environment.

5. Activate the Don’t override the pipeline’s header configuration with the following new configuration option if you don’t want to override the values of the headers configured in the pipelines with the values of the policy’s headers. If you keep this option deactivated, the values will be overridden.

The headers are only overridden if they have the same key in both the policy and the pipeline. If they don’t have the same key, the headers from the pipeline and the policy are added together in the response.

1. Click Add key and value to add a new key-value pair of information. Enter the data in the corresponding key and value fields. The CORS HTTP header policy validates each key-value pair. Here are some examples of the accepted values:

• Access-Control-Allow-Origin: http://example.com, https://sub.example.com, *

• Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS, PATCH, HEAD

• Access-Control-Allow-Headers: Content-Type, X-Requested-With, Authorization, Accept, Origin

• Access-Control-Allow-Credentials: true, false

• Access-Control-Expose-Headers: Content-Length, ETag, X-My-Custom-Header, X-Another-Custom-Header

• Access-Control-Max-Age: 600, 3600 (time in seconds)

1. You can delete any key-value pair by clicking the X icon.

It may take a few minutes for the headers to be applied to all pipelines.

You can edit the policy at any time by following the steps described above or view the configuration in read-only mode by clicking the eye icon.

Use case: overriding the pipeline’s header configuration with the policy configuration

Suppose you have a payment API that is used by multiple e-commerce websites. These websites are hosted in different domains and need to communicate with your API to process payment transactions.

Without CORS headers, the requests made through the clients' browser from a specific domain, for example, “ecommerce1.com”, to your API hosted in another domain, for example, “api.payments.com”, would be blocked due to the same-origin policy. This policy is a browser security resource that prevents a website from making requests to another domain. To allow e-commerce websites to access your payment API, you need to add CORS headers to your API.

Now let’s imagine two situations:

Situation 1: you don’t want to override the pipeline’s header configuration

In this first situation, we assume that your pipelines should only accept requests from the domain “ecommerce1.com”, but if this domain is not specified in the pipeline header, it should accept any domain.

In this case, this should be the policy configuration:

• Don’t override the pipeline’s header configuration with the following new configuration option activated.

• Key-value pair: Access-Control-Allow-Origin: *.

This means that the values configured in each pipeline will override the values defined in the policy. So if you create a pipeline and add the key-value pair Access-Control-Allow-Origin: ecommerce1.com, the header of the pipeline will take precedence over the header configured in the policy.

However, if you don’t add a header with the Access-Control-Allow-Origin key with a specific domain to your pipeline, any domain will be accepted as Access-Control-Allow-Origin: * header is configured in the policy, which will be considered instead.

Situation 2: you want to override the pipeline’s header configuration

Now let’s assume that your pipelines should always accept requests from any domain, regardless of whether the pipeline has a header indicating that only a specific domain should make requests.

In this case, this should be the policy configuration:

• Don’t override the pipeline’s header configuration with the following new configuration option deactivated.

• Key-value pair: Access-Control-Allow-Origin: *.

This means that regardless of whether the pipeline configuration contains the Access-Control-Allow-Origin header configured with a specific domain, the Access-Control-Allow-Origin: * header that is configured in the policy is taken into account instead.