Configure Cross-Origin Resource Sharing in Bold Reports

Search results

Think about a situation where you want to update the user information in Bold Reports using a web app that is hosted in a different domain. To accomplish this, you must make an API request from your web app, which is hosted in a different domain, to the Bold Reports API domain. However, what if a fraudster uses an application interface that is identical to yours and uses this API to gain access to user data? Implementing the appropriate CORS configuration will stop this kind of attack and secure your application.

CORS is a browser security feature called cross-origin resource sharing (CORS) that limits cross-origin HTTP requests made by a browser. When an HTTP request is sent from one origin to a different domain, sub-domain, port, or protocol, it is referred to as a cross-origin request.

How its works

Browsers limit cross-origin HTTP requests due to security concerns. For example, when a browser requests data from one site to another, it makes cross-origin requests. The browser sends a pre-flight HTTP request with the OPTIONS method to the resource on the other domain before sending the actual request. This is done to ensure the safety of submitting the actual request. In the pre-flight request, the server includes headers in the responses it provides.

These are the pre-flight response headers:

Access-Control-Allow-Origin
Access-Control-Allow-Methods
Access-Control-Allow-Headers
Access-Control-Allow-Credentials
Access-Control-Expose-Headers
Access-Control-Max-Age

Based on the header values, the browser decides whether to send the actual request or not. Otherwise, the browser will throw a CORS error and not send the actual request.

Important: Bold Reports uses CORS for XMLHttpRequest or Fetch requests to avoid the risks of cross-origin HTTP requests. This will not affect the iFrame-based embedding since this request will be considered as the document request, not an XMLHttpRequest or Fetch request.

Default CORS policy in Bold Reports

The default CORS policy automatically allows all cross-origin requests from cross-domains with different origins, methods, and headers.

Enabling CORS in Bold Reports

The default CORS policy is used until you enable and customize the CORS settings in Bold Reports. Please follow the steps below to enable CORS and customize it in Bold Reports.

Steps to enable CORS

Go to the administration page on the Bold Reports site and click the CORS Policy tab. Here, you can configure CORS settings headers.
By default it is disabled. You should enable the Customize CORS Policy option if you want to configure a custom CORS policy.
The application will include the value from the Allowed Origins field in the pre-flight response Access-Control-Allow-Origin header. The application will check the incoming origin value and include this origin in the Access-Control-Allow-Origin header like Access-Control-Allow-Origin: <origin> if it is added to the Allowed Origins field. If no value is updated in this field, then it will include a wildcard origin value in the header like Access-Control-Allow-Origin: *.

A web browser will grant access to the actual request response if the Access-Control-Allow-Origin and the origin of the requesting website match or the Access-Control-Allow-Origin header has a wildcard origin value.
The application will include the value from the Allowed Methods field in the pre-flight response Access-Control-Allow-Methods header, like Access-Control-Allow-Methods: <method>, <method>. If no value is updated in this field, then it will include a wildcard method value in the header, like Access-Control-Allow-Methods: *.

A web browser will grant access to the actual request response if the Access-Control-Allow-Methods header has the requesting method or the Access-Control-Allow-Methods header has a wildcard allow method value.
The application will include the value from the Allowed Headers field in the pre-flight response Access-Control-Allow-Headers header like Access-Control-Allow-Headers: <header name>, <header name>. If no value is updated in this field, then it will include a wildcard method value in the header like Access-Control-Allow-Headers: *.

If you send a custom request header with the request, the web browser will grant access to the actual request response if the Access-Control-Allow-Headers has the custom request headers or the Access-Control-Allow-Headers header has a wildcard allow header value.
CORS automatically excludes cookies from cross-origin requests as a default behavior. This sets it apart from other cross-origin methods such as JSON-P, which always includes cookies in the request. This practice of including cookies in JSON-P requests exposes systems to a type of security vulnerabilities called cross-site request forgery (CSRF).

When we set “allow credentials” to true, the CORS response will be sent with the header Access-Control-Allow-Credentials: true. This informs the browser that both the server and the client must agree to include cookies in the request. As a result, cookies become a deliberate choice rather than an uncontrollable, passive event.
Application will include the value from the Expose Headers field in the pre-flight response Access-Control-Expose-Headers header like Access-Control-Expose-Headers: <header name>, <header name>. If no value is updated in this field, then it will include a wildcard header value in the header like Access-Control-Expose-Headers: *.

If Access-Control-Expose-Headers contains response headers or a wildcard value for the expose header, the web browser can access or read the response header at the script level. By default, only the response headers that are deemed safe according to CORS guidelines are exposed such as Cache-Control and Content-Type .
The application will include the value from the pre-flight Max-Age field in the pre-flight response Access-Control-Max-Age header, like Access-Control-Max-Age: <delta-seconds>. If no value is updated in this field, then it will include a default value in the header, like Access-Control-Max-Age: 5.

The response header value indicates how long the results of a pre-flight request (that is the information contained in the Access-Control-Allow-Methods and Access-Control-Allow-Headers) can be cached in the browser.