Serverless and the Dreaded CORS

While venturing farther in the Serverless world, I started making a list of things I encountered on my journey that I would like to delve deeper into; plainly because, I figured learning just enough to make something work was never going to satisfy my voracious appetite. Towards cementing my understanding, I started making unorganized one-liner notes as reference material. This article (and the ones that will follow, hopefully) are logical extensions of those notepad entries.

My very first entry on the list, was CORS - more commonly known as Cross Origin Resource Sharing.

1. So what EXACTLY is CORS?
   Cross Origin Resource Sharing (CORS) enables a web-app to access resources OUTSIDE of its domain in a controlled manner and offers flexibility + functionality over the default same-origin security policy.

2. What is Same-Origin Security Policy?
   A policy, under which, a web browser permits web page #1 to access data in web page # 2, ONLY IF both web pages have the same origin i.e. belong to the same domain.

3. How is CORS relevant in Serverless?
   Web API Backends being a popular use case in serverless, a web page might need to make calls to a backend API that lies on a different domain i.e. of different origin; therefore, requiring the call to be CORS-friendly.

4. What is a common error indicating that CORS is NOT enabled?
   No 'Access-Control-Allow-Origin' header is present on the requested resource

5. How is CORS implemented?
   Two main ways:

   • Headers
     • Access-Control-Allow-Origin header: Included in the response to specify the origin of where the request originated from as the value for allowing access to the resource's contents.
   • Pre-flight requests (GET, POST, HEAD methods excluded)
     • Browser will send a preflight request to the resource using the OPTIONS method; in response to which, the resource you're requesting will return with methods that are safe to send and may optionally return the headers that are valid to send across.

6. Ways that CORS can be exploited? (i.e. Poor design practices)

   • Allowing access to any domain in the origin field
   • Allowing access to all sub-domains (including currently non-existent sub-domains, that could potentially be malicious)
   • Origin header specification supporting the value null
   • Trusting origins with vulnerabilities to XSS i.e. Cross Site Scripting
   • Whitelisting trusted subdomain using HTTP
   • Lower security standards for authentication on intranets/internal websites

7. Ways to prevent CORS-based attacks?

   • Allowing trusted websites ONLY
   • Avoid whitelisting null
   • Avoid use of wildcards in intranets/internal websites
   • Judiciously configure cross-domain requests by correctly specifying origin against Access-Control-Allow-Origin header
   • Stringent configuration of server-side security policies.

Credits: Major shout-out to Alex DeBrie for his amazing article on Serverless and CORS that helped me a lot while writing this post.