How do I enable CORS in Bold Reports^® Cloud Reporting?

In Bold Reports^® Cloud, you configure Cross-Origin Resource Sharing (CORS) in the CORS Policy tab of the administration page to control which origins, methods, and headers can make cross-origin requests.

For example, 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 CORS works

The browser first sends a pre-flight OPTIONS request, and the CORS headers in the response decide whether it sends the actual cross-origin request.

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 ensures that the actual request is safe to submit. 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 allows all cross-origin requests from any origin, method, and header until you turn on Customize CORS Policy.

How to enable CORS

You enable a custom CORS policy by turning on Customize CORS Policy in the CORS Policy tab of the administration page. Until you do, the default CORS policy is used.

Steps to enable CORS

Go to the administration page on the Bold Reports^® site and select the CORS Policy tab.
Turn on Customize CORS Policy. This option is disabled by default.
In Allowed Origins, enter the origins that can make cross-origin requests. The application includes this value 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 you leave this field empty, the header includes a wildcard origin value, like Access-Control-Allow-Origin: *.

A web browser grants access to the actual request response when the Access-Control-Allow-Origin value matches the origin of the requesting website. The browser also grants access when the Access-Control-Allow-Origin header has a wildcard origin value.
In Allowed Methods, enter the allowed HTTP methods. The application includes this value in the pre-flight response Access-Control-Allow-Methods header, like Access-Control-Allow-Methods: <method>, <method>. If you leave this field empty, the header includes a wildcard method value, like Access-Control-Allow-Methods: *.

A web browser grants access to the actual request response when the Access-Control-Allow-Methods header includes the requesting method. The browser also grants access when the Access-Control-Allow-Methods header has a wildcard allow method value.
In Allowed Headers, enter the allowed request headers. The application includes this value in the pre-flight response Access-Control-Allow-Headers header, like Access-Control-Allow-Headers: <header name>, <header name>. If you leave this field empty, the header includes a wildcard header value, like Access-Control-Allow-Headers: *.

If you send a custom request header with the request, the web browser grants access to the actual request response when Access-Control-Allow-Headers includes the custom request headers. The browser also grants access when 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. Including cookies in JSON-P requests exposes systems to a type of security vulnerability called cross-site request forgery (CSRF).

When you set “allow credentials” to true, the CORS response includes 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.
In Expose Headers, enter the response headers that scripts can read. The application includes this value in the pre-flight response Access-Control-Expose-Headers header, like Access-Control-Expose-Headers: <header name>, <header name>. If you leave this field empty, the header includes a wildcard header value, like Access-Control-Expose-Headers: *.

The web browser can access or read a response header at the script level when Access-Control-Expose-Headers contains that response header. The browser can also do so when the header has a wildcard expose header value. 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 you leave this field empty, the header includes a default value, like Access-Control-Max-Age: 5.

This response header value indicates how long the browser can cache the results of a pre-flight request. These results are the information in the Access-Control-Allow-Methods and Access-Control-Allow-Headers headers.

CORS settings and values when left empty

The following table lists the CORS settings, the header each one sets, and the value used when you leave the field empty.

Setting	Response header	Value when empty
Allowed Origins	`Access-Control-Allow-Origin`	`*`
Allowed Methods	`Access-Control-Allow-Methods`	`*`
Allowed Headers	`Access-Control-Allow-Headers`	`*`
Allow Credentials	`Access-Control-Allow-Credentials`	Added as `true` only when you turn it on
Expose Headers	`Access-Control-Expose-Headers`	`*`
Preflight Max-Age	`Access-Control-Max-Age`	`5`

Frequently asked questions

Does the CORS policy affect iframe embedding?

No. Cloud Reporting applies CORS to XMLHttpRequest and Fetch requests only. An iframe request is a document request, so iframe-based embedding is not affected.

What is the default CORS policy?

By default, Customize CORS Policy is disabled, and the default policy allows all cross-origin requests from any origin, method, and header.

Why does my browser show a CORS error after I customize the policy?

The browser blocks the request when the preflight response headers do not match it. Add the requesting origin, method, or custom header to the matching CORS field, and then save.

How do I enable CORS in Bold Reports® Cloud Reporting?