# How to use the CORS policy on the Digibee Integration Platform
**CORS (Cross-Origin Resource Sharing)** is a security policy implemented by web browsers that allows a server to restrict which origins can access its resources through HTTP requests.
Using CORS is recommended whenever a web application needs to make HTTP requests to resources located on a different domain or port from where the application is hosted. This helps protect the server from malicious attacks that might attempt to access resources inappropriately.
## How it works
When a web page makes a request to a different domain, the browser will first send a **Preflight request** to that domain's server. In this “test request”, the server responds with a set of headers indicating whether the request is allowed. If the request is permitted, the browser proceeds with the actual request.
### Headers
Some of the most common headers used in CORS include:
* **Access-Control-Allow-Origin**: Specifies which origins are allowed to access the resource. It can be a single value (value: `*`), allowing any origin to access the resource, or a list of specific domains.
* **Access-Control-Allow-Methods**: Specifies which HTTP methods are allowed for the resource request (for example, `GET`, `POST`, `DELETE`).
* **Access-Control-Allow-Headers**: Specifies which custom headers are allowed in the resource request. This is necessary for sending custom headers like `Authorization`.
* **Access-Control-Expose-Headers**: Specifies which custom headers are exposed in the resource response.
* **Access-Control-Allow-Credentials**: Specifies whether the resource can be accessed with credentials (for example, cookies, authorization headers, and so on) from the requesting origin.
## CORS on the Digibee Integration Platform
The CORS policy is available for the following triggers:
* [**HTTP**](https://app.gitbook.com/s/EKM2LD3uNAckQgy1OUyZ/triggers/web-protocols/http)
* [**HTTP File (Download and Upload)**](https://app.gitbook.com/s/EKM2LD3uNAckQgy1OUyZ/triggers/web-protocols/http-file)
* [**REST**](https://app.gitbook.com/s/EKM2LD3uNAckQgy1OUyZ/triggers/web-protocols/rest)
CORS can be configured individually within pipelines, or globally for the entire realm through the [Global CORS Configuration.](https://app.gitbook.com/s/jvO5S91EQURCEhbZOuuZ/platform-administration/governance/policies/transformation/cors-http-header)
## Example
### CORS policy configuration in a pipeline trigger
For this example:
* The [**REST Trigger**](https://app.gitbook.com/s/EKM2LD3uNAckQgy1OUyZ/triggers/web-protocols/rest) is configured with the `GET` and `OPTIONS` methods.
* During setup, CORS is enabled and the CORS headers are defined as follows:
* **Access-Control-Allow-Origin** to allow any origin (value: `*`).
* **Access-Control-Allow-Methods** to allow only the `GET` method.
* **Access-Control-Allow-Headers** to allow requests containing only the headers `Authorization`, `Content-Type`, and `apikey.`
Example 1: Successful request (authorized by the browser)
A request is made through Google Chrome using the `GET` method and the headers `Content-Type` and `apikey`.
The browser sends a **Preflight** request to the Digibee endpoint using the `OPTIONS` method, which returns the CORS headers. Since the request complies with the CORS policy configured in the pipeline trigger, the `GET` request is authorized.
The `GET` request returned successfully and it’s now possible to continue with the normal pipeline flow.
Example 2: Unsuccessful request (denied by the browser)
The same request is made, but this time with an additional header: `test`.
Since the `test` header is not authorized in the CORS configuration, the request is blocked by the CORS policy and the `GET` request will not get to Digibee.
Example 3: Unsuccessful request (denied by the browser)
In this case, the headers comply with the CORS policy, but the `POST` method used in the browser request is not configured in the trigger. This results in a **404 Not Found** error.
.png)
