How to secure your Heroku application

Heroku security

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 before going 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?

Where to start our security efforts?

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

Image result for dependabot pull request
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, it’s smart to protect against attackers exploiting vulnerabilities in your own 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, authentication is done via some form of key, secret, or password. Whatever the precise method you use, it’s important to ensure that these credentials are not leaked from your application.

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 a secret is leaked in version control, it’s likely still accessible in the history, even if it’s not obvious on the surface.

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, “If this credential were compromised, what is the damage that could be caused?” 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 your applications are built 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.

Notify of
Inline Feedbacks
View all comments
You May Also Like