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.
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!
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
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
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.