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.”
Insufficient logging — Solved with 3rd party tools such as Dashbird or becoming well versed in using CloudWatch.
Insecure storing of app secrets — Solved by using AWS KMS to encrypt your application secrets.
DoS attacks and financial exhaustion — Solved with writing efficient code, using timeouts and throttling.
Improper exception handling — Solved by logging stack traces only to the console or dedicated log files. Never send stack traces back to the end user.
One of the many companies that do serverless security, Protego came up with an analogy I really like.
“It’s a bit like riding in an Uber vs. taking your own car. Sure, the drivers are probably more professional, and perhaps better trained. And the flexibility of paying for a car only when you need it is great. At the same time, you don’t get to choose which safety features the car has, or how many airbags you’ll have around you.”
And while all these are really cool, with serverless we need to look for security flaws in a different place and this is something that doesn’t come easily to anyone. Having to manage deployment permission alongside the many new points of attack is going to prove challenging but not impossible if you know where to look. Here’s where Dashbird comes into play. It gives you the observability you lack in your serverless environment while providing monitoring and alerting to help you get the most of your new serverless application.
Failure detection, analytics and visibility for serverless applications in under 5 minutes.