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 on Matthew Henry 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 for keeping secrets (i.e. authentication tokens) and sensitive user data. LocalStorage Stop doing it as soon as you can! I know, I know, 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 , 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. LocalStorage LocalStorage In case you are not convinced and have some more time to read about this issue, read , by Randall Degges. Trust me, it will convince you. Please stop using local storage Ok, this security vulnerability might not be affecting 9 in 10 serverless apps, could be more, could be less. Anyway, using for this purpose is a very common thing and I can’t stress enough how important it is to rethink this approach. LocalStorage We hate cookies, but we shouldn’t Photo by on Food Photographer | Jennifer Pallian 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 , it doesn’t mean you must have a application, so bear with me in the next lines. LocalStorage stateful Using a JWT ( ) — 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 , 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. JSON Web Token LocalStorage 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 , 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 and note the flag we mentioned. httpOnly Mozilla Cookie Specification httpOnly This is also in line with directives for . OWASP using cookies and LocalStorage Photo by on Pablo García Saldaña 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 service with 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. API Gateway Lambda 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. has tremendously good resources. OWASP We live in a fun and rich, but dangerous internet and you can never be . A great ally in your quest to secure a serverless application is your logs. If you are recording the and can efficiently access these logs to your benefit, you will have a good head start to prevent and mitigate malicious attacks. too safe right information
Share Your Thoughts