According to wikipedia’s article, “cross-origin resource sharing (CORS) is a web browser technology specification that defines ways for a web server to allow its resources to be accessed by a web page from a different domain”. CORS was originally introduced in VoiceXML specification back in 2004, as a way to allow exemptions to browser’s same origin policy (SOP) security model.

In fact, there are certain situations where the use of client-side requests to load resources from external APIs would be more effective than having your own server acting like a proxy. A good example would be a corporate web portal displaying real-time stock quotes. Web applications traditionally would handle the entire process, downloading and formatting the information then serve it back to the user’s browser. By using CORS, it could simply push some script code and consume client-side’s computational resources to download and render the same information while saving some CPU in the server’s side.

You may find other initiatives that serve the same purpose such as “JSON with padding” (JSONP) which already have been deployed long before to allow cross-origin resource sharing, however, CORS has introduced a simpler protocol to share external resources.

Possible Security Implications

Allowing cross-origin requests on browsers are inherently insecure. A normal request made to an application will carry all identification tokens such as cookies and session identification thus can be used to impersonate actions on behalf of the user. Certain attacks such as Cross-Site Request Forgery (CSRF) exploits this specific trust model. CORS got away with that by explicitly not allowing credentials to be provided within different origins. However there are certain points to be considered when exposing a public API:

• Allowing stateless authentication via CORS (i.e: token sent as a GET/POST parameter) might still allow an attacker  to execute CSRF attack in certain cases, for example if an application is vulnerable to XSS attacks. In that case, the CORS-enabled application will happily allow the CSRF attack.

• A CORS-enabled application can be configured to allow credentials via “Access-Control-Allow-Credentials”.  In that case, the scenario above with a vulnerable application will be valid even if a session token is provided within a cookie parameter.  Same thing might happen with a customized HTTP header via “Access-Control-Allow-Headers”.

Conclusion

Web apps are becoming more complex, integrated and resources dependent from external providers. The use of client-side’s computational resources might be an answer to serve a more cost-effective system. In that scenario, CORS is becoming a “de-facto” solution to a traditional problem emerged in a cross-domain security model as  it allows to circumvent that restriction but also providing a transparent security policy to avoid misuse.

If you need to expose your application to cross-domain requests, we recommend you to follow these guidelines:

• If possible, restrict the URLs (origin) allowed to consume your service (avoid “Access-Control-Allow-Origin: *”). A more restricted environment allows you to control and monitor security;
• If you plan to have an unrestricted origin (such as “*”):
  • Do not allow your application’s credentials to be sent (avoid “Access-Control-Allow-Credentials: true”);
  • Do not allow header or method customization (via Access-Control-Allow-Methods or Headers);

N-Stalker Web application Security Scanner allows you to assess the security of your application’s CORS policy. Download Free Edition to get started.