In the world of web development, security is a paramount concern. One of the critical security mechanisms that often confuses developers is CORS, or Cross-Origin Resource Sharing. In this guide, we will dive into what CORS is, why it can be a problem for MPages and how we can work around it.
What is CORS? #
CORS stands for Cross-Origin Resource Sharing. It is a security feature implemented by web browsers to prevent malicious websites from accessing resources from a different origin (domain, protocol, or port) than their own. Essentially, CORS is a way for servers to say, “This website is allowed to access my resources,” helping to protect user data and prevent security vulnerabilities.
A simple example #
Imagine you navigate to example.com. Your browser loads the home page from example.com. The page might have JavaScript code that makes an API call to getdata.com. When your browser tries to fetch data from getdata.com, which is a different website (a different “origin”) from example.com, it sends a request to getdata.com asking for permission. If the webserver at getdata.com trusts example.com, it sends back a response with special headers saying, “Yes, you can access my data.” If getdata.com does not have example.com on its list of trusted sites, it responds saying it does not trust example.com, and the browser blocks the call to getdata.com. When the browser does not enforce the CORS protocol, then the browser makes to API call to the webserver at getdata.com ignoring the security concerns from getdata.com.
It’s important to note that it’s up to the browser to enforce the CORS protocol. A webserver can decide not to respond to a request but that would be a separate security mechanism from the CORS protocol.
How can CORE be a problem for MPages #
Let’s say you have a legitimate MPage stored in your static content directory. The MPage contains JavaScript code that makes an API call to, for example, https://ehrenhancify.net/api/make-predecition-be/ to obtain a prediction of whether the patient has diabetes or not. Let’s assume our domain does not block API calls to https://ehrenhancify.net/api/make-predecition-be/.
When you load the MPage, you are using PowerChart’s embedded browser to make a localhost call to the MPage html file. PowerChart’s embedded browser displays the MPage html and attempts to make the API call. The embedded browser can either enforce the CORS security protocol or not.
When making an API call, the embedded browser let’s the web server at ehrenhancify.net know that this request is coming from “localhost”. The web server at ehrenhancify.net responds by saying it doesn’t trust calls from “localhost” as “localhost” is not listed in the set of domains it trusts. If the embedded browser is set to enforce the CORS protocol, it will block the API call. If it is set to not enforce CORS, it will proceed in making the API call, obtain the data and pass it on the JavaScript code.
PowerChart’s embedded browser: Internet Explorer vs Edge #
By default, Internet Explorer does not enforce CORS whereas Edge does. This is the reason why your API call in your MPage might stop to work once you set your PowerChart Emebded browser to be Edge.
Working around CORS #
You cannot simply decide to continue using Internet Explorer as newer versions of MPages will remove the possibility of using Internet Explorer. So sooner or later, you will have to use Edge.
The solution is for the API call not to be made from the PowerChart’s embedded browser. You have mainly two options:
Using a proxy web server to make the API call #
In this solution, the JavaScript code in the MPage would make an API call to your own internal proxy webserver that you would be able to set to trust requests coming from localhost. The proxy server would then make the final API call.
Using CCL to make the API #
This solution might be easier to implement as you wouldn’t need to set up an entire web server to manage API calls. You just need a CCL script that handles the API call and invoke it from your MPage with JavaScript. You can see our related guide for an example.
Conclusion #
CORS doesn’t need to be a CURSE – especially if you understand what the CORS protocol try to prevent. All you need is to structure your MPage to avoid it. You can find a good example on our web site.
