How to use the CORS policy on the Digibee Integration Platform

Understand how the CORS policy works and how to use it in 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

• HTTP File (Download and Upload)

• REST

CORS can be configured individually within pipelines, or globally for the entire realm through the Global CORS Configuration.

Example

CORS policy configuration in a pipeline trigger

For this example:

• The REST Trigger 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.