Forgotten staging and test servers: the part nobody watches

A forgotten staging or test server is a copy of your website or app that was set up for development and then left running on the internet. It usually sits on a name like staging.yourcompany.com, dev.yourcompany.com or test2.yourcompany.com, nobody checks it any more, and it often runs older code with weaker settings than production.

These servers matter because they are part of your company's internet presence even though nobody treats them that way. They do not get the same updates, logins or monitoring as the main site, yet they frequently share the same database copies, API keys and admin accounts.

The good news: they are easy to find, and once found, the fix is usually simple. This article shows how to look for them and what to do with each one.

Why staging servers get forgotten

A staging server is created for a good reason: to test a release before customers see it. Then the release ships, the developer moves to another project or the agency contract ends, and the server keeps running because switching it off was never on anyone's task list. Common patterns:

• A full copy of production, including a recent database dump, so testing looks realistic.
• Debug mode left on, showing stack traces, configuration values or framework details.
• Default or shared admin passwords that were "only for testing".
• Old versions of the CMS, plugins or libraries that production has since updated.
• No HTTPS, or a certificate that expired months ago.
• Search engine indexing that was never blocked, so the test site shows up next to the real one.

None of this is dramatic on its own. Together, it means a host under your own domain that is weaker than everything around it.

How these servers become visible

You do not need to publish a link for a staging host to be found. 3 common ways:

1. Certificate Transparency. When a publicly trusted certificate is issued for staging.yourcompany.com, the name is written into public logs (the protocol is described in RFC 9162). Anyone can search those logs, as explained in Certificate Transparency logs explained.
2. DNS records. A record that still points to the server makes it reachable by name, and guessable names like dev, test and beta are tried first.
3. Search engines and archives. A test site without indexing rules can appear in search results, and old pages stay in web archives.

How to find your own forgotten servers

Start with the names, then check each one.

1. Search crt.sh for %.yourcompany.com and collect every hostname.
2. Look through your DNS zone for names like dev, stage, staging, test, uat, beta, old, demo, preview.
3. Resolve each and check the response:

dig +short staging.yourcompany.com
curl -sI https://staging.yourcompany.com

1. Open each host in a browser and ask: does it show real customer data, a login form, a debug page, a default server page or an error from a hosting platform?
2. Look for files that should never be served. The OWASP testing guide covers this in WSTG-CONF-04, noting that backup files tend to be served as plain text rather than executed. Our article on exposed .env, .git and backup files lists the usual names.

If a name points to a hosting platform that shows a "no such app" or "bucket not found" page, treat it as urgent: that is the classic setup for subdomain takeover.

What to do with each one

For every staging or test host, pick one of 3 outcomes.

Remove it. If nobody can name its owner and purpose, shut down the server and delete the DNS record. Delete the record after the server, not before, and never leave a CNAME pointing to a service you no longer pay for.

Restrict it. If the team still needs it, put it behind authentication or an IP allow list. HTTP Basic authentication is quick to add, but MDN notes that it must be used over HTTPS because credentials are only base64 encoded. A VPN or an identity aware proxy is a better long term choice.

Clean it. Staging should not hold real customer data. Use generated or masked data, separate API keys with limited rights, and turn off debug output.

Keeping search engines away is useful but is not protection. Google documents noindex as a way to keep pages out of results, via <meta name="robots" content="noindex"> or an X-Robots-Tag header (Google Search Central). The page is still reachable by anyone who has the address.

X-Robots-Tag: noindex

A short checklist

• Every non-production host has a named owner and an end date.
• No real customer data on staging.
• Staging requires a login or sits behind a VPN.
• Debug mode off, separate keys, no shared admin passwords.
• Valid certificate, or the host is removed.
• DNS records deleted when the server is.
• The list is reviewed after every project ends, not once a year.

Where Datahorses fits

Datahorses watches your company from the outside every day, including new hostnames under your domains, forgotten subdomains and test servers, and exposed files on them. Each finding comes with exact steps for your developer, and we do not enter your systems or need any access. See what we guard and what happens when we find something.