We’ve seen time and again how serverless architecture can benefit your application, graceful scaling, cost efficiency and a fast production time are just some of the things you think of when talking about serverless. But what about security? What do I need to do to ensure my application is not prone to attacks? This is exactly what I’m going to try to address today so let’s jump right in!

From a developer perspective serverless architecture, switching to serverless is a great move as it allows them to focus on the product itself while the platform on which the code executes is run by the province provider. What this means for security is that the patches themselves are being applied on time everytime which is one of the biggest “challenges” for traditional servers. Basically, the people responsible for the security updates either forget or just ignore said updates, leaving you and your data at great risk.

It’s not all fun and games!

While the architecture has some clear advantages over its traditional counterpart, serverless has some security disadvantages (yeah, let’s call them that). I’ll quickly go over a few but if you want to go into details you can check out Adnan’s article on the issue where he talks about finding the biggest security risks in serverless.

Event injection — Solved with input validation and predefined database layer logic, such as an ORM or stored procedures.

Broken authentication — Solved with built-in authentication/authorization solutions and avoiding dangerous deployment settings.

Insecure deployment settings — Solved with never using public read ACLs and keeping files encrypted.

Misuse of permissions and roles — Solved with the “least privilege principle.”

#serverless