Securing serverless applications

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!

“Serverless security is not inherently better or worse, it’s just different. ” – Guy Podjarny

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 every time 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.

“Most attacks exploit known vulnerabilities that have never been patched despite patches being available for months or years” – Verizon

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 read our Serverless Security article based on AWS Well-Architected Framework.

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


To summarize, with serverless, the new kid on the block a lot of things got easier from a security perspective, things like the need to patch servers which are now done by the service providers, or the microservices that got smaller and easier to control and not to mention the fact that each container is stateless and ephemeral.

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.

Read our blog

ANNOUNCEMENT: new pricing and the end of free tier

Today we are announcing a new, updated pricing model and the end of free tier for Dashbird.

4 Tips for AWS Lambda Performance Optimization

In this article, we’re covering 4 tips for AWS Lambda optimization for production. Covering error handling, memory provisioning, monitoring, performance, and more.

AWS Lambda Free Tier: Where Are The Limits?

In this article we’ll go through the ins and outs of AWS Lambda pricing model, how it works, what additional charges you might be looking at and what’s in the fine print.

Made by developers for developers

Dashbird was born out of our own need for an enhanced serverless debugging and monitoring tool, and we take pride in being developers.

What our customers say

Dashbird gives us a simple and easy to use tool to have peace of mind and know that all of our Serverless functions are running correctly. We are instantly aware now if there’s a problem. We love the fact that we have enough information in the Slack notification itself to take appropriate action immediately and know exactly where the issue occurred.

Thanks to Dashbird the time to discover the occurrence of an issue reduced from 2-4 hours to a matter of seconds or minutes. It also means that hundreds of dollars are saved every month.

Great onboarding: it takes just a couple of minutes to connect an AWS account to an organization in Dashbird. The UI is clean and gives a good overview of what is happening with the Lambdas and API Gateways in the account.

I mean, it is just extremely time-saving. It’s so efficient! I don’t think it’s an exaggeration or dramatic to say that Dashbird has been a lifesaver for us.

Dashbird provides an easier interface to monitor and debug problems with our Lambdas. Relevant logs are simple to find and view. Dashbird’s support has been good, and they take product suggestions with grace.

Great UI. Easy to navigate through CloudWatch logs. Simple setup.

Dashbird helped us refine the size of our Lambdas, resulting in significantly reduced costs. We have Dashbird alert us in seconds via email when any of our functions behaves abnormally. Their app immediately makes the cause and severity of errors obvious.