Cross-Origin Resource Sharing support

Posted on March 22, 2017 by Mathijs Brand

 

Your browser knows a trick to prevent hackers from accessing your api’s using your session: the same-origin policy. It makes sure your api's can't be accessed by malicious websites. Let's say you're logged in on facebook.com and open another tab in your browser and access myhackedsite.com. Your browser shares sessions between tabs, so without the same-origin policy, myhackedsite.com could access all the api's from your facebook account using your session. Thank you same-origin policy for not letting myhackedsite.com post all kinds of weird things on my facebook timeline.

Great, let's not trust any site other than our own and we're good to go. Mysite.com can do all communication with myapi.com using secure protocols like SAML. Right?

Yes, that's right. But let’s say you want to use a client side javascript framework like Angular to build mysite.com and want to access myapi.com directly without going through server side code on mysite.com? How would you do that securely? SAML doesn't work securely because it relies on a trusted communication between mysite.com and myapi.com.  Your javascript framework does not run on mysite.com. It runs in your browser on your customers laptop or so. If you'd allow communication between your customers laptop, you'd also allow myhackedsite.com to access the api.

W3C created a way to separate the good from the bad by adding the CORS protocol. It allows you to specify which origin web server to trust and which you don't. A script may run on your customers laptop, but your browser knows its origin is mysite.com and not myhackedsite.com. Myapi.com trusts the browser's origin header. 


CORS basic example:

You run your Angular site on mysite.com and your MSP secured api’s are running on myapi.com. Now, mysite.com tells the server its origin with the Origin header, and the server can then specify it accepts mysite.com by setting the Access-Control-Allow-Origin header as depicted in the image below: 

 

CORS.png

 

In the image above you see an HTTP Get request, you could do the same for a POST or HEAD request. 

 

CORS preflight example:

In some cases (e.g. if a request has implications on user data)  a simple request may be insufficient. For that reason most modern browsers add a step by checking if the browser (user) is allowed to perform an action. An OPTIONS request is then followed by the actual request.

CORS Preflight.png

 

Configure CORS in your token server

Ideally you don't open up all api's to mysite.com, just the ones you need. In the Token server we made this easy for you. You configure the url's and the sites as follows:

Configure CORS.png

 

Can you change the origin header?

By default the MSP platform does not allow any access other than same-origin. As explained, you can configure your MSP platform to trust a certain host. One way you could hack around it is if you would be able to set the origin header from myhackedsite.com to mysite.com. This way the server would trust you and you may be able to access myapi.com. But this is not easy to do as all modern browsers prevent you from changing the origin header. You'd need to hack the browser, but if you would be able to do so, you'd be able to access anything from the user, not only access myapi.com.  

Read more?

Special thanks to Marta Kobylinska for reviewing this blog post. 

White paper: Digital Transformation Insurance Companies

Stay up to date

Sign up for newsletter