CORS (Cross-Origin Resource Sharing) is a security policy implemented by web browsers that allow a server to restrict which origins can access its resources through HTTP requests.
It is recommended to use CORS whenever a web application needs to make HTTP requests for resources on a domain or port different from where the application is hosted. This helps protect the server against malicious attacks that may attempt to access resources improperly.
How does it work?
When a web page makes a request to a different domain, the browser will first send a "Preflight" request to the server of that domain to check if the request is allowed. The server will respond with a set of headers indicating whether the request is allowed or not. If the request is allowed, then the browser will send 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 (*), which allows any origin to access the resource, or a list of specific domains.
Access-Control-Allow-Methods: Specifies which HTTP methods are allowed in the resource request (e.g., GET, POST, DELETE, etc.).
Access-Control-Allow-Headers: Specifies which custom headers are allowed in the resource request. This is necessary so that a custom header like "Authorization" can be sent with the request.
Access-Control-Expose-Headers: Specifies which custom headers are exposed to the resource request.
Access-Control-Allow-Credentials: Specifies whether the resource can be accessed with credentials (e.g., cookies, authorization headers, etc.) by the requesting origin.
CORS in Digibee
CORS can be used individually in pipelines, or it can be configured for the entire realm through the Global CORS Configuration.
Example
We authorize the GET and OPTIONS methods for the REST trigger in the pipeline. We activate CORS and define the Access-Control-Allow-Origin header to accept any (*) origin, Access-Control-Allow-Methods to accept only the GET method, and Access-Control-Allow-Headers to accept requests that may contain only the Authorization, Content-Type, and apikey headers.
Successful Request (Authorized by the browser)
We made a request through the Google Chrome browser using the GET method and the Content-Type and apikey headers.
The browser performs a "Preflight" to the Digibee endpoint using the OPTIONS method, which returns the CORS headers. Since the request complies with the CORS policy defined in the Pipeline trigger configuration, we are authorized to proceed with the GET request.
Now we proceed with the normal flow of the pipeline, which would be the GET request, which is returned successfully.
Example of an unsuccessful request 1 (denied by the browser)
We make the same request but added the "test" header to our request.
Since the "test" header was not authorized, the request was blocked by the CORS policy. The GET request will not reach Digibee.
Example of an unsuccessful request 2 (denied by the browser)
In this example, the headers comply with the CORS policy, but the verb used by the call in the browser is not configured in our trigger.
This will generate a 404 Not Found error.
