A customer searching for their own name found a test copy of a company’s booking system, sitting on a subdomain with no login and a nightly refresh from the production database. Nothing was exploited. Nothing needed to be. The site was indexed, the records were readable, and the incident became reportable the moment somebody outside the business could see personal data they had no right to see.
How the site ended up public
Nobody made a decision to publish it. The environment was built during a replatforming project, given a subdomain so the client could review progress, and protected by the fact that the address was not advertised. The team added a robots.txt file to keep search engines away, which is a request rather than a control, and later a developer linked to the site from a public ticket. Once one link existed, indexing followed. The nightly data refresh had been added for realistic testing months earlier, and by the time anyone reviewed it, the environment held around four thousand customer records with names, addresses and booking histories.
What the response looked like
The first hour went on confirming exposure rather than fixing it, which was the right call. The team captured the indexed pages as evidence, checked web server logs to see who had visited and from where, and only then took the site offline. Logs showed a handful of search engine crawlers, one visit from the customer who reported it, and nothing else. That evidence shaped everything afterwards. Under UK GDPR the Information Commissioner’s Office expects notification of a reportable personal data breach within 72 hours of becoming aware of it, and being able to show a bounded exposure window is the difference between a difficult conversation and a very expensive one.
“The instinct is always to delete the thing immediately, and that instinct destroys the evidence you need to prove the exposure was limited. Take the logs first, take a copy of what was visible, then pull it down. I would rather explain a ten minute delay than tell a regulator we cannot say who accessed the data because we wiped the server.”
William Fieldhouse, Director, Aardwolf Security Ltd
Image: Picture19.jpg | Alt text: Cyber crime tape over binary code representing a reportable data breach investigation
Caption: An incident does not need an attacker to become notifiable.
The controls that would have stopped it
Three changes would each have prevented this, and the company adopted all of them. Test environments now get masked data, generated by a script that replaces names, addresses and contact details while keeping the shape of the records. Every non-production host sits behind an authenticating proxy tied to staff accounts, so an unknown visitor never reaches the application. Certificate transparency logs and DNS records are reviewed monthly against a list of environments the team believes exist, which is how forgotten hosts surface. A web application security test now covers staging as well as production, because the two rarely stay identical.
Finding your own version of this
Assume you have one, then go looking. Search your domain in a browser with the site operator to see what is indexed. Query certificate transparency logs for every certificate issued to your domains in the past two years and match them against the hosts you can name. Ask your development team which environments hold a copy of live data, and ask when each was last refreshed. External network testing does this systematically and finds hosts nobody remembers, though the internal question about data copies is one only your own team can answer.
Frequently asked questions about exposed test environments
These questions follow almost every incident of this kind.
Does an exposure with no evidence of misuse need reporting?
Often yes. The test is whether the breach poses a risk to people’s rights and freedoms, not whether someone downloaded the data. Document your reasoning either way, because the Information Commissioner’s Office expects to see how you reached the decision.
Is masked data enough for testing?
For most testing, yes, and it removes the whole class of problem. Where a genuine production copy is unavoidable, treat that environment exactly like production, including access control, monitoring and retention limits.
