Heroku Security: Securing your Heroku application

I’m guessing you’re here because you’ve got an application up on Heroku, and you’re wondering what steps you need to take to keep it secure. If so, then awesome—you’re in the right place.

In this post, we’re going to be talking about securing applications on Heroku. We’ll first consider how we should think about security on a platform as a service (PaaS) like Heroku. Then discuss how to prioritize security issues based on the highest probability of attack vectors. And finally, go through three big-impact techniques to apply to your Heroku application. Ready to secure your application? Let’s get to it.

Why secure your application?

I might be preaching to the choir with this section, given that you’re the type of person who reads articles about security. You clearly aren’t ignorant to how important security is. But, nonetheless, let’s take a moment to highlight why application security should be a top priority for you and your company, even when you’re running on a PaaS solution like Heroku.

Security is hard in an ever-changing environment. Attackers are currently scanning the internet day and night using high-performance tools. If you accidentally open up a vulnerability in your application, it could be just moments before their tool finds that crack, that vulnerability, and you become exploited. In a worst-case scenario, an attacker could use their access to blackmail the company or tarnish your brand by selling user data on the black market. No matter what the attacker chooses to do, it’s bad news for you and your company.

So, I think it’s safe to say that the stakes are high. The bigger your company grows, the bigger a target it becomes. And securing your application should be a high priority for you and your business. But I know what you’re thinking: Hey, we’re running on Heroku! They handle most of this for us. Well, kind of. Let’s take a closer look at what security Heroku handles and what we need to deal with ourselves.

Security in a PaaS world

Before we dive into the specifics of how we can improve security on our Heroku application, let’s pause to consider where the boundaries of our responsibilities lie. Take a look at the “Separation of Responsibilities” graph at this webpage.

Heroku is known as a PaaS. This means that we have more responsibility than when using a software as a service (such as Jira or GitHub) but less responsibility than when using an infrastructure as a service (like AWS or GCP). And we definitely have less responsibility than running our own data center. So, with a PaaS, we’re somewhere in the middle in terms of our security responsibilities; some things we can ignore, but other things we should still consider.

With a PaaS setup, we’re not as responsible for topics like network security or ensuring that data is appropriately encrypted in storage. So, we can worry less about those—thanks, Heroku! But if Heroku is helping to deal with those bits, what’s left to deal with?

We still have the responsibility of securing the application. Heroku will ensure that intruders can’t access our infrastructure through a side door, but we need to secure our application so an intruder can’t just walk straight through the front door, proverbially speaking.

So, to ensure that our application is secure, what should we focus on?

Heroku security: Where to start?

Securing applications is not a one-step process. It’s a continuous practice that happens throughout the lifecycle of the application. And you need to take up one thing at a time and work on it. But how do you decide which ones to consider first and which ones later? A smart way to approach this is to focus on the most probable issues first. Once this is done, you can walk your way through less probable and then application-specific issues.

Highest Probability Attack Vectors

If we’re focusing on security, it makes sense to work on the highest value—the areas that are most likely to be attacked. The OWASP Top 10 is a great place to start when securing your application. Begin by fixing some of the highest probability attack vectors in your application. 

With this list in mind, let’s look at three ways we can protect our application from vulnerabilities while on Heroku.

Update your dependencies and monitor against attacks

An example Dependabot pull request

In many modern applications, it’s common to have many third-party dependencies. In most applications, these third-party libraries make up the majority of our code. This means that one of the largest attack vectors sits outside of our code repository and in a repository belonging to someone else.

To protect ourselves from potential vulnerabilities, we can ensure that we’re running the latest and patched versions of these third-party dependencies. Since it’s quite likely that you’re running a lot of them, keeping track of where you’re at with all your dependencies can be hard.

A simple way to manage dependencies is with a tool such as Sqreen. Depending on your ecosystem and language, there will be a dependency tool out there to automate these checks, identify which dependencies are outdated, and what vulnerabilities you’re exposed to. 

Beyond being vigilant against vulnerabilities in your dependencies, you should be smart enough to protect your application against attackers exploiting vulnerabilities in your code or in your dependencies before they get patched. Using automation is a great way to scale your security efforts and to ensure that you can monitor and protect your application in real time. In fact, Heroku has a whole list of security add-ons that you can use for different security efforts, including monitoring and protection tools like Sqreen, which will help you go that extra step with your application security.

Keep secrets secret

An example encryption using OpenSSL

Unless your application is living in isolation, it’s probably connected to other services. And most applications connected to other services require some form of authentication to do so. Typically, applications handle authentication via some form of key, secret, or password. Whatever the precise method you use, it’s important to ensure that your application and authentication mechanism doesn’t leak these credentials.

To keep our secrets safe, we should encrypt them before we ever store them in version control—or, even better, avoid storing them in version control where possible. Why avoid version control for secrets? Because even private version control isn’t immune from attack. A disgruntled ex-colleague can easily gain access to systems if they retain the code post-employment. And remember that if version control has a secret leak, it’s likely still accessible in the history, even if it’s not obvious on the surface.

Allowlist, Validate, and Sanitize

User input is the main point of attack for most cyberattacks. And when a user gives a harmful input, results are catastrophic. Injections are one of the most dangerous attacks originating from inputs. No matter how hard you try, you can’t completely control what a user gives as input. But you can take precautions to make input data safe before using it.

Allow listing is only allowing the payloads that you know are legit. Allow only those input values that should be allowed and block everything else.

Validate inputs before using them. For example, if the input field is an email address, then when the user submits the request, check if the input is in a valid email address format or not. This would decrease the number of malicious payloads that could be successful.

Sanitizing input is your big gun especially in web application security. Sanitizing is making the input safe to use. When you sanitize data, you are converting the input to an equivalent safe format. This would make the malicious parts of the payload useless.

Apply the “principle of least privilege”

A deploy command restricted through credentials

On the topic of secrets, we should ensure that our secrets have the smallest access (or privilege) possible. It’s easy to get a bit blasé and grant users or credentials full admin rights. Fiddling with security rules can be a pain—I get it. But large permission grants would be like a dream come true for an attacker.

If a potential attacker compromises our secrets or keys, it’s important that we keep our “blast radius” (the amount of damage a potential attacker can cause) to a minimum. We can ensure small blast radiuses when we judiciously apply the principle of least privilege to our application boundaries and secrets.

Take a common Heroku example: databases. Do you currently have a database hosted on Heroku? If so, then do all of your developers need full access to the database? And for those who don’t need full access, can you give these developers read-only access? Or perhaps access only to certain environments, such as test rather than production?

You should question who has access to your different resources and proceed with scrutiny when you delegate power and permissions to both individuals or credentials. Ask yourself, “What damage would the compromise of these credentials cause?” A simple place to start is by locking down your Heroku user access rights.

Keep it secure

That covers the three security practices that you can apply to your Heroku application. I hope this article gave you some insight into ways you can start to lock down your Heroku application.

Because you’re using a PaaS, you do have less responsibility—but that doesn’t mean you should reduce your security diligence. You still need to actively focus on ensuring that you build applications with security in mind. If we do our security right, we can sleep easy knowing that our application, data, and users are safe.

This post was written by Lou Bichard. Lou is a JavaScript full stack engineer with a passion for culture, approach, and delivery. He believes the best products emerge from high performing teams and practices. Lou is a fan and advocate of old-school lean and systems thinking, XP, continuous delivery, and DevOps.