Every company we assess has two versions of itself. The production one, which the team defends, and the pre-production one: staging, QA, dev, UAT, preview. The second one is where the rules relax. Weaker authentication, no bot protection, older code, sandbox integrations. It does not count, the thinking goes. It is not real.

Attackers do not make that distinction. To them, staging is the same application with fewer guards and, very often, the same data.

In our latest batch of assessments, 23 percent of the applications we attacked exposed a non-production environment to the public internet. This is the third finding in our field series. We have covered endpoints that never ask who you are and internal tools that are not internal. Staging is where those two problems meet.

What staging exposure is

Staging exposure means a pre-production environment, built for testing and never hardened for the public, answers requests from the internet. MITRE classifies the underlying pattern as CWE-489, Active Debug Code: code and infrastructure deployed with doors that were only ever meant for the people building it.

The environment itself is rarely the whole finding. The finding is what staging carries: a copy of the application with the controls turned down, frequently connected to production data, production user accounts, or production third-party keys.

What an attacker finds in staging

No exploit required. Staging environments announce themselves on predictable hostnames, and they answer. Real findings from recent engagements, anonymized:

A company with decades of shipping experience ran staging and production on the same user accounts. Register or probe on staging, and you are touching production identities. There was no identity separation between the two environments at all.
A payments company's dev environment answered anonymous API calls with no key required, on the same API where production enforces a key on every request. The middleware that guards production was simply never enabled there.
An insurance platform's dev and stage APIs were publicly reachable and carried data close to production, across a whole family of forgotten hostnames.
A scheduling tool's QA environment allowed programmatic signups with no bot check, where production gates registration. We created accounts by script, at will.
A healthcare company's staging subdomain served a public admin console login, one credential pair away from an operations interface.
An AI company shipped its entire staging configuration inside its production JavaScript bundle: staging hostnames, staging keys, environment topology. Production code was the map to the softer estate.
In one open-source product, we verified a state-changing endpoint that had been fixed in production but stayed wide open in QA, and in the public code every self-hosted customer runs. The patch never made it to the branch people actually deploy.

Notice the pattern in the last two. Staging exposure is not only about forgotten servers. It leaks through the build pipeline, and it lingers through patch drift.

Worth saying: production at these companies was usually the hardened estate, and it held up under direct testing. The soft target was everything built around it.

Why this is a real problem

Staging matters to an attacker for three reasons, and none of them require staging to be "important."

First, the data. Non-production environments routinely hold production data, or something close to it: a database copy from last quarter, real customer records used for a realistic test, live third-party keys because the sandbox ones were inconvenient. A breach of staging with production data is a production breach with extra steps.

Second, the map. Staging reveals how the real system is put together: API routes not yet public, middleware that will guard tomorrow's release, internal hostnames, integration partners. An attacker planning against production rehearses on staging, where nobody is watching the logs.

Third, the path across. Shared user stores, shared keys, and shared infrastructure turn a staging compromise into a production one. And the drift problem cuts the other way too: a fix that lands in production but not in the branch, or in QA, leaves a documented, reproducible vulnerability in the wild. For a healthcare or payments company, each of these is a regulator's question you do not want to answer.

Why staging stays open

The reasons are reasonable. That is what makes the pattern so durable.

Testing genuinely needs reachability. Third-party webhooks, payment provider callbacks, and mobile builds cannot hit a machine behind the VPN, so staging goes public "temporarily" and stays. Convenience wins the daily vote. A gate on staging adds friction to every QA cycle, and your own engineers are the ones who feel it. And the assumption underneath it all, it is not real data, is often no longer true by the time anyone checks. The database snapshot from March had real customers in it. Nobody remembers approving that.

Then there is drift. Production gets the patch because production gets the attention. QA and the public source tree lag behind, and the gap between them is exactly where we keep finding live vulnerabilities.

How to secure staging environments

The fix is policy enforced by architecture, not reminders. Four steps.

Step one. Decide what staging is allowed to hold. Synthetic data only, generated on refresh. Separate user accounts, separate keys, separate third-party credentials, no exceptions. If staging must test against a live integration, use the provider's sandbox mode and rotate the credentials on a schedule. This single decision removes most of the blast radius.

Step two. Gate the environment by default. An identity-aware proxy, IP allowlist, or VPN boundary in front of every non-production hostname. For the endpoints that genuinely must be public, webhook receivers and callback URLs, expose exactly those routes, not the whole application.

Step three. Kill drift. Deploy patches to every environment from the same pipeline, so production is never ahead of the branch your customers or testers run. Alert when environments diverge. A fix that exists only in production is a fix that does not exist for everyone running your code.

Step four. Include non-production in every test. Scope staging into your assessments and re-test it after meaningful changes. It drifts faster than production, so point-in-time reviews age out even quicker there. The check has to return when the software changes, and non-production software changes constantly. That is the model we run: continuous, not annual.

Frequently asked questions

Is staging part of my attack surface?

Yes. If a hostname resolves publicly and answers requests, attackers count it, regardless of what your team calls it. Staging, QA, dev, UAT, and preview environments are standard enumeration targets precisely because they run the same application with weaker controls.

Can a company get breached through staging if production is secure?

Yes, and it happens through three routes: staging holds production data, staging shares credentials or user accounts with production, or staging reveals unreleased code and internal topology that makes attacking production easier. Hardening production while leaving staging open protects one door of a two-door building.

Should staging ever contain production data?

No. Use generated synthetic data refreshed on a schedule. If a test genuinely requires realistic data, anonymize it before it leaves production: strip identifiers, tokenize account numbers, and never copy credentials, sessions, or secrets. A staging database with real customer records makes staging a production-grade target.

How do I keep staging reachable for webhooks and integrations safely?

Expose only the specific callback routes third parties need, behind path-level routing rules, and gate everything else. Use provider sandbox modes and separate credentials for non-production. If an integration cannot sandbox, restrict by source IP or verified request signatures.

What is environment drift?

Environment drift is the growing difference between production and every other environment: patches applied in one place and not another, configuration that diverges over time, features tested in QA that never match what ships. That is how a fix verified in production leaves the same vulnerability live everywhere else.

The point

We keep finding staging environments in the open because they are built to be convenient, and convenience compounds. Every temporary exception becomes permanent unless something removes it.

If you want to know where you stand, it takes a few minutes. Try the predictable hostnames against your own domain: staging, qa, dev, uat, test, preview. See which ones resolve, which ones answer, and which ones greet you with a login page or, better for the attacker, no login page at all. Then check whether your staging database remembers more about your customers than your policies allow.

And if you would rather have someone enumerate the whole estate, production and everything around it, and keep watching as it changes, that is exactly what we do.

Related reading: Your Internal Tools Are Not Internal, the dashboards and admin panels that follow the same pattern. And The Finding We Report More Than Any Other, the endpoints that skip the check, on 45 percent of the applications we attack.