9 in 10 Serverless Apps Are In Deep Trouble In Frontend Security

9 in 10 Serverless Apps Are In Deep Trouble In Frontend Security

We all hate security breaches and we all get bored at investigating ways to protect our applications. Let’s face: it’s much more thrilling to create a new and loved feature than securing possible vulnerabilities someone might exploit someday just to piss everyone off. Nevertheless, none of us want to get caught as being lazy in securing our software and that’s why we care about security to the highest standards.

Photo by Matthew Henry on Unsplash

Flexible is not always secure

Many security vulnerabilities come from too many flexibilities or not following the least privilege principle, for example. In frontend apps, this issue arises from using the LocalStorage for keeping secrets (i.e. authentication tokens) and sensitive user data.

Stop doing it as soon as you can!

I know, I know, LocalStorage is very cool: it’s pure JavaScript, it’s flexible to store data, comes with an easy API, supported by all major browsers, yes, yes, it’s lovely. But, for the same reasons, it’s also a devil. By storing sensitive information in LocalStorage, you are making this data accessible to anyone who comes to execute JavaScript in your app. If an attacker finds a way to somehow inject and execute JS code, you are doomed, since he’ll be able to virtually steal every logged user’s sensitive information. Heck, it’s possible that this person could even impersonate any user and start making requests on behalf of him/her without you knowing it.

In case you are not convinced and have some more time to read about this issue, read Please stop using local storage, by Randall Degges. Trust me, it will convince you.

Ok, this security vulnerability might not be affecting 9 in 10 serverless apps, could be more, could be less. Anyway, using LocalStorage for this purpose is a very common thing and I can’t stress enough how important it is to rethink this approach.

We hate cookies, but we shouldn’t

Photo by Food Photographer | Jennifer Pallian on Unsplash

Look, I don’t like cookies either, but they come to our rescue when it comes to securing authentication tokens and sensitive user data.

I know what you’re thinking: “Hey, but it’s not right to start managing cookies in a distributed serverless architecture such as AWS Lambda”!

Well, by using cookies instead of LocalStorage, it doesn’t mean you must have a stateful application, so bear with me in the next lines.

Using a JWT (JSON Web Token) — or a similar strategy — to secure a web application is very common nowadays. We basically pack into a hash: a few user information, such as username, email, etc, some application data and a validation hashing mechanism to preserve the token integrity. What developers relatively often do is store the JWT in LocalStorage, which makes it easy to grab and send along with requests to the backend for authentication and authorization purposes. The problem with this implementation is the immense security risk we mentioned above.

Cookies done right in serverless

To clear your app from this vulnerability, the JWT (or any other type of auth token) should be set by the application as a cookie. Also, make sure it stays away from JavaScript fingers. Cookies, by default, can be accessed by JS as well, but there’s a flag you can set called httpOnly, which tells the browser that a particular cookie should be used only in HTTP calls, staying away from local JS code. See, for instance, the Mozilla Cookie Specification and note the httpOnly flag we mentioned.

This is also in line with OWASP directives for using cookies and LocalStorage.

Photo by Pablo García Saldaña on Unsplash

Setting up cookies from a traditional web server is usually simple. In serverless architectures, it’s not that straightforward. In AWS, for example, you can use the API Gateway service with Lambda to expose custom cookies to your application. Once a cookie is set in the user browser (containing a JWT, for example), it will accompany all further requests to the backend. Your Lambda function can then parse the cookie, extract the token, authenticate the user and authorize the operation just as you would normally do.

The AWS team published an easy to follow tutorial explaining how to do that: Using AWS Lambda to Expose Custom Cookies with API Gateway.

There’s never too much security

Now that you learned about this common vulnerability and a simple way to fix it, keep studying how to better secure your applications. OWASP has tremendously good resources.

We live in a fun and rich, but dangerous internet and you can never be too safe. A great ally in your quest to secure a serverless application is your logs. If you are recording the right information and can efficiently access these logs to your benefit, you will have a good head start to prevent and mitigate malicious attacks.