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?
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:
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.
Configure CORS in your token server
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.
Special thanks to Marta Kobylinska for reviewing this blog post.