Getting started
Chart interface
Web components
Chart internals
Data integration
Frameworks and bundlers
Mobile development
Time Span Events
Term structures

Cross-Origin Resource Sharing (CORS)

Sharing resouces, such as data and files, between different points of origin poses security risks. Points of origin differ when their domains or the protocols or ports they're using differ. For example, an HTML page on site aaa.com cannot automatically access data from bbb.com.

CORS restrictions are the default behavior of all browsers, so if you want to mash up data you need to take specific steps. In this tutorial, we summarize three ways of managing CORS.

See enable cross-origin resource sharing for an in-depth discussion of CORS.

Note: As of version 8.0.0, the ChartIQ sample template files and any other HTML files that import ChartIQ modules must be loaded using HTTP or HTTPS to prevent CORS errors. ChartIQ is made up of ES6 modules. ES6 requires the special CORS HTTP headers for cross-origin resource sharing. Files that import ChartIQ modules, including the sample templates, cannot be loaded using a file:/// URI or by double‑clicking or double‑tapping the files.

Add "access-control-allow-origin: *" header to server responses from bbb.com

If a response from bbb.com contains this header then the browser will allow code from aaa.com to use the data. In some ways, this is the best path to take because it is standard's based and the direction the web is heading. However, this approach requires that you control or have cooperation from bbb.com.

In many cases though, API vendors have security concerns with this approach since "*" basically applies to anyone on the Internet. Mostly such concerns are unfounded, but a cautious vendor could be more restrictive by blocking access based on a known list of referrers (that is, their server would allow requests only from "aaa.com"); unfortunately, specifying a domain in the header itself (access-control-allow-origin: aaa.com) does not work well because the standard requires an exact url match. http://aaa.com and https://aaa.com and https://www.aaa.com would each require an exact match, which would require server side code at bbb.com. (The lack of support for wildcards is a severe oversight which we hope the W3C will address in future standards.)

Put a server in between

Assuming you are unable to get the cooperation of your server vendor to bypass a CORS issue, the next best alternative is to interject your own server. Instead of accessing bbb.com directly your browser, code will need to access aaa.com/yourscript. This server side script (php, perl, python, ruby, node, etc) would then query bbb.com for the data and return it to the browser. (This is how all data integration was done until just a few years ago and still how 80% of the web works).

A quick alternative to writing scripting code is to use a generic proxy server that simply forwards the data (a "reverse proxy"). In many cases this would be our recommendation. For instance, one would proxy aaa.com/myproxylabel to bbb.com. The data transfer will pass through your proxy server but will obviate the need for the access-control-allow-origin header.

A sample apache http.conf (on aaa.com) would look like this:

ProxyPass /myservice/ http://bbb.com/


JSONP is not so much a protocol as it is a technique, but it bypasses the CORS security restrictions in a browser. Many API vendors offer JSONP based solutions. If you're using jQuery then it is very easy to make a JSONP request as the code is interchangable with AJAX requests. This is another approach we recommend. However, this requires your data server explicitly support JSONP.

Next steps