In Depth: Protecting Staging Sites!
[InDepth#23] Staging sites usually contain buggy code, debugging tools, and lower security than production, while also being a gateway into your environment and sometimes even contain customer data...
Staging environments are an incredibly important part of the development lifecycle. Developers write their code and push it onto staging so it can be tested in a production-like environment, either by themselves or other members of the team, or even clients.
Note: I’ll be using the term “staging” throughout this article, but I’m talking about any non-production environment. There are many common names: QA, Testing, Staging, etc.
If you work in an office or over a VPN, you may keep your staging site within your internal network, but it’s incredibly common for staging sites to be online and world-accessible. It’s also common for them to be found at domains like staging.company.com or test.company.com, just waiting to be found (and attacked).
It’s easy to consider staging sites as low-risk and not worry about them being attacked, either because you think no one will bother attacking them, or because you think they don’t contain any sensitive production data. However, that’s a very dangerous assumption to make… Staging is a gateway into your application, a direct line to your developers, a potential data leak waiting to happen, and sometimes even a pivot point into your production environment!
Let’s dive deeper into the two main questions:
- Why is staging so vulnerable?
- How can we protect staging?
Before we begin, it’s worth pointing out that staging sites can come in all shapes and sizes. Your staging might be massive and require code approach to deploy, or maybe it automatically updates every time you push to main and hosts a trivial application. As such, some of the risks and recommendations may not exactly match your environment - that’s ok. If you’re unsure how to apply things, jump in the comments or email me and we can start a discussion.
Why Is Staging So Vulnerable?
Buggy and/or Untested Code
Staging is where we deploy our untested or unreviewed code to be tested before being deployed to production. We generally don’t require full PR approval to get on staging, but rather push up quickly to “see it in action” and test against our staging data and send it over to other team members to check.
This means that staging, by it’s very nature, will have more vulnerabilities and weaknesses than production - which will make them much easier to find and exploit. Staging is also known to contain abandoned and incomplete features, both of which can introduce vulnerabilities that would never hit production.
Shared Primary Domain
It’s very tempting to set up your staging sites with friendly subdomains on your primary domain, such as staging.company.com alongside app.company.com. It feels nice to have it all under the primary domain, however there are a few problems with this approach:
