# CORS HTTP header

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.

<figure><img src="https://content.gitbook.com/content/jvO5S91EQURCEhbZOuuZ/blobs/GFUq6cRCXqzUp3wb5vHA/cors-http-header-overview.png" alt=""><figcaption></figcaption></figure>

## 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.

{% hint style="warning" %}
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.
{% endhint %}

6. 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)

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

{% hint style="info" %}
It may take a few minutes for the headers to be applied to all pipelines.
{% endhint %}

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.

{% embed url="<https://files.gitbook.com/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F4523BaA7JfghHEYBbLWY%2Fuploads%2FMgIqJKw0RGmiU6fStb0i%2Fconfigure-cors-header.mp4?alt=media&token=83dc896a-5c8c-4603-8b1a-6b7c18b7d4bb>" %}

### 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.