The Problem with CORSPrinciple: a web page is an application, and in order for web pages to remain relevant in an app-driven world, web-apps should be able to do anything a native app can - with the user’s permission where appropriate.
CORS breaks this principle. It restricts the information a web-app can fetch from the internet, and even if you are allowed to fetch it, it sometimes restricts what you can do with that information. Native Apps can fetch anything from the internet and do anything with it.
CORS has other problems as well. It isn’t consistently implemented across browsers. Safari 9.x interprets HTMLImage.crossOrigin differently from other browsers. CORS setup is difficult to get right and therefor it’s easy to get it wrong and actually create exactly the vulnerabilities CORS is supposed to prevent. Last, CORS returns extremely opaque errors: http://stackoverflow.com/questions/4844643/is-it-possible-to-trap-cors-errors .
Why Does CORS Exist?I’ve been trying to understand this question for a year. My best understanding is, before CORS, web-apps were even more restricted. CORS opens up cross-domain access while preventing hacks such as:
- Badwebsite.com attempts to fetch your emails from gmail.com; if you are logged in with gmail.com, without cors, it could do this!
- CORS “taint” - I just don’t know. Is this a way to appease copyright holders? It doesn’t really prevent anything since Native Apps aren’t restricted in this way. Further, all you have to do is set up a basic web-proxy server and your Web-App could do anything with any image on the web.
CORS is the Wrong AnswerReason #1 above is the main reason for CORS. It is legitimate from a certain perspective. There is a potential vulnerability, but it is the wrong solution. The problem is when “badwebsite.com” attempts to contact “gmail.com” it gets to freely use your cookies authenticated with gmail.com. This is something Native-Apps cannot do, so why should a web-page get to do this? And yet IT CAN - without CORS restrictions. This is insane. It’s like logging into the Gmail Native App on your phone , and then switching to MyMalicousApp and allowing it to send requests to Gmail using your login information from the Gmail app.
Beyond CORSIt is relatively easy to solve the CORS problem now that we have separated the essence from the artifacts. We just need a way to allow websites to make external requests without giving them access to all the client’s cookies. The answer is to treat each webpage as a separate, isolated application with its own, sandboxed set of cookies for all the other webpages it communicates with.
I propose we add an option to XMLHttpRequest called ‘useSandboxedCookies’. When true, any web-application for a given domain is now allowed to make any request to any url - just like any native app could. However, all cookies used in those requests are local to that web application. This is exactly how native-apps works.
- Alice logs into Gmail.com directly.
- Then she goes to MyWebsite.com, which attempts a GET from Gmail.com
- The cookies in the GET request to gmail.com are empty - the GET originated in the sandboxed cookie-space of the MyWebsite.com app.
- So, even though the Alice is logged into Gmail.com in one tab, in the MyWebsite.com tab, requests to Gmail.com appear to be coming from a new session.
This solution doesn’t actually do anything you can’t already do with CORS. All you need to do is set up a proxy server, which returns all the right CORS headers, and any website can fetch data from anywhere on the net, taint-free. However, setting up a proxy is not generally an option because it is costly and inefficient. We need a client-side solution like the one above.
Safe, Cross-Web-App CommunicationThere are legitimate reasons why MyGoodWebsite might want to access Gmail.com using your logged in credentials, and Gmail.com may want to allow it. For example, Gmail.com may want to offer a ‘log in with Gmail’ feature to third-party web apps. With my proposal above prevents this since the only client-side code allowed to access your gmail.com cookies is gmail.com’s code itself.
In the example above, MyGoodWebsite could postMessage to gmail.com/api.js. Once the gmail app loads, it sends back a postMessage that it is ready. Then MyGoodWebsite can use Gmail’s custom API for authentication. The gmail.com/api.js app can then use the user’s already-authenticated gmail.com cookies to communicate with the gmail.com servers and authenticate the third-party app.