In short and in plain language
Next to your shop, there are often old leftovers. For example, an old test version or a preview from the last redesign. They can often still be reached online.
These leftovers get no updates. Some contain real customer data. That is a risk.
The article shows how to clean up. First, you make a list of all leftovers. Then you decide for each entry: switch off, archive or lock.
We make this list at the start of our support. After that, we check it as a fixed point in the maintenance plan.
A well-maintained shop rarely stands alone. Next to it sits the preview of the last relaunch on its own subdomain, the web directory still holds a folder with the previous installation, and somewhere in the DNS zone a record points at a service that was cancelled two years ago. These leftovers receive no updates, often carry real customer data, and are still reachable from the internet. During the BSI reporting period, an average of 119 new vulnerabilities per day became known worldwide (BSI, IT Security Situation Report 2025) – they hit the copy next to the maintained system just as they hit the system itself, only nobody looks there. This article describes how to build an inventory you can rely on, which criteria decide each entry, and how a one-off cleanup becomes a recurring date in the maintenance plan.
Key takeaways
- The inventory comes from several sources, not from memory: DNS zone, web server configuration, issued certificates, search index, file system and invoices. Germany's web attack surface comprised roughly 13.2 million internet-reachable .de domains in the second quarter of 2025 (BSI, Situation Report 2025).
- Every test system needs an end date. The IT-Grundschutz standard calls for a documented rule: procedures should be documented for how the test environment is to be handled once the software test is complete (BSI, IT-Grundschutz OPS.1.1.6.A13).
- Test data taken from a copy of the production database is personal data. It must at minimum be pseudonymised (BSI, OPS.1.1.6.A11), and the storage limitation principle of Article 5(1)(e) GDPR applies to the copy exactly as it does to the original.
- A DNS record whose target has disappeared is not a dead record but an open one. OWASP describes it as a dangling DNS record: an entry pointing to an external resource that no longer exists or has been deprovisioned (OWASP, Web Security Testing Guide).
- Exploitation of vulnerabilities was the starting point for 20 percent of the analysed breaches with a known access vector (Verizon, DBIR 2025). Of the exploited edge device vulnerabilities, only about 54 percent were fully remediated over the year, taking a median of 32 days.
Why the copy next door weighs more than the original
Maintenance goes where the revenue is. That is where updates land, where monitoring runs, where somebody actually reads the log. The rest of the environment drops out of that attention without disappearing: the preview of a relaunch stays up after the switchover because it still seemed useful for follow-up questions. An older shop version stays in a subdirectory because the migration had to be quick. A second shop built for a trade fair was left standing after the event, only removed from the navigation. Each of these systems is reachable at an address, and every reachable address gets queried – regardless of whether any menu links to it.
The BSI has measured how large that surface is in total: Germany's web attack surface comprised roughly 13.2 million internet-reachable .de domains in the second quarter of 2025 (BSI, Situation Report 2025). For 47 percent of the reachable IP addresses behind those domains, sensitive information was publicly visible from the internet, including geographic data or indications of possible vulnerabilities (BSI). That figure describes visibility, not breaches – and visibility is the step that precedes every access. For a single shop it means: whatever answers from the internet belongs to your own attack surface, even if internally it has long counted as switched off.
A test system rarely carries only test data
The inventory: what actually exists
The list does not come from memory. Written from recollection, it captures the systems that come up in conversation – and those are the smaller problem. The inventory only becomes reliable once it draws on sources that are kept independently of one another: the DNS zone at the provider, the web server configuration, the issued certificates, the file system and the invoices. Wherever two of those sources disagree, you will usually find an entry that no one has owned for a long time.
That even well-equipped organisations have gaps here is shown by a BSI measurement of its own administration: during the reporting period, an average of roughly 3,800 IP addresses of the federal administration were reachable from the internet, and about 7 percent of them showed a suspected vulnerability (BSI, Situation Report 2025). For a shop with a handful of subdomains the number is smaller, but the mechanics are the same: reachability is created faster than it is documented. Taking over maintenance from another provider is typically the moment when the gap between list and reality turns out to be particularly wide.
| Where it sits | What is typically there | Why it becomes a risk | How it becomes visible |
|---|---|---|---|
| Subdomain from a relaunch | Full copy of the shop, often with real order data | Receives no updates but is fully operable | Compare the DNS zone against issued certificates |
| Subdirectory of the previous version | Older shop version under its own path | Runs under the same domain and reaches the same database | Directory listing in the web root, modification date per folder |
| Database dump in the web directory | Dump, archive or export from a migration | Downloadable without a login and full of customer data | Targeted requests for common file names |
| DNS record without a reachable target | Pointer to a cancelled service | Can be claimed by third parties under your name | Resolve each record and have the target confirmed |
| Service provider test access | Own subdomain with its own access protection | Survives the project, ownership is unclear | Compare with contract and invoice documents |
| Preview or maintenance page | Static page from an earlier switchover | Sits in the search index and displaces the live page | Query the indexed addresses of the domain |
The table shows a pattern: no single entry is unusual, each had a good reason once. Time is what turns it into a risk. A staging environment with a clear job belongs in every orderly update chain; the problem is the copy that stayed up after the project ended even though its purpose was fulfilled. The difference between the two is organisational rather than technical: a test system needs an end date, and whoever owns the ongoing security updates needs the list of systems those updates are meant to cover.
Six places where the list comes from
Six sources together produce a list you can verify. None of them is sufficient on its own; their strength lies in having different vantage points, so their blind spots sit in different places. It works well to collect them in one pass and lay the results side by side, rather than working through one source after another.
The DNS zone
The zone at the provider lists every name that can be resolved at all. It is typically the only place that also holds the records pointing at external targets – and therefore the basis for everything that is later removed or repointed.
The web server configuration
Every configured server name answers requests, even without a link in the navigation. A listing of the configured names together with their document roots reveals systems that no longer appear in the zone at all.
Issued certificates
Certificates are logged publicly. Reviewing the certificates issued for your own domain surfaces subdomain names that dropped out of sight in day-to-day work long ago.
The search index
Whatever a search service returns for the domain was publicly reachable at least once. The comparison reveals addresses that have left operations but still receive visitors.
Directories in the web root
A look at the file system separates maintained applications from parked copies: folders with older versions, archives from the last migration, database dumps. The modification date per folder puts them in order.
Contracts and invoices
Hosting, certificates and add-on services appear on invoices. A line item that cannot be matched to any system on the list points to an access that keeps running without being used.
The DNS zone deserves particular attention because it serves two purposes at once: it controls what is reachable, and it documents what ought to be reachable. If you already have DNS record upkeep with locks and monitoring in place, extend it with a second question: every record needs a target that somebody can name. Where that answer stays open, the record is a candidate for the next cleanup date.
Shut down, archive or lock down
Once the list exists, each entry gets one of three decisions. Shut down means: the service is stopped, the files are backed up and removed, the DNS record leaves the zone. Archive means: the content is taken out of operation but kept traceable – outside the served directory, encrypted, and with an end to the retention period. Lock down means: the system stays in operation but is restricted to a named group of people and removed from the search index.
The decision follows the purpose, not the technology. A test system needed for the next version jump is locked down and maintained alongside. A test system with no planned next use is shut down – the effort of setting up a second, clean system later is usually smaller than the risk of leaving an unmaintained one open for months. Retention obligations concern the data, not the running application: if you need to keep records, export them instead of keeping the old shop alive. What applies to invoice data shifts again with the move to electronic invoicing – one more reason to separate archiving from operations cleanly.
# Restrict a test site: access only from the office network and with a login,
# no entry in the search index, no delivery of dumps.
server {
server_name staging.example.invalid;
root /var/www/staging/public;
add_header X-Robots-Tag "noindex, nofollow" always;
location / {
satisfy all;
allow 203.0.113.0/24; # office network
deny all;
auth_basic "Test site";
auth_basic_user_file /etc/nginx/access/staging.htpasswd;
try_files $uri $uri/ /index.php$is_args$args;
}
# Dumps, archives and metadata folders are not served at all
location ~* \.(sql|sql\.gz|zip|tar|tar\.gz|bak|log)$ { return 404; }
location ~ /\.(git|env|svn|idea) { return 404; }
}
The configuration does three things at once: it restricts access to a named network plus a login, it sets the response header for search engines, and it answers requests for dumps, archives and metadata directories with an error. That third point is often forgotten: access protection in front of the application helps little if an unprotected archive sits next to it in the same directory. The network shown comes from an address range reserved for documentation and is replaced by your own.
Locking down calls for the same care as production. A locked system is still a system: it needs updates, a log and a responsible person. Using the lock as a substitute for maintenance only moves the problem – to a place where it is noticed less often. Access protection tied to the same two passwords for years belongs in the access inventory and offboarding routine.
The DNS record that points nowhere
Of all the leftovers, a DNS record without a target rarely draws attention. It creates no load, appears in no shop log, and is invisible when you look at the site. OWASP describes it as a dangling DNS record: an entry pointing to an external resource that no longer exists or has been deprovisioned (OWASP, Web Security Testing Guide). If such a record points at a service where names can be claimed freely, a third party can take the released name and serve content under your subdomain.
That is why the test procedure in the Web Security Testing Guide starts with an enumeration: Enumerate all possible domains (previous and current) – collect previous and current names, then check that every record has a resource genuinely attributable to your own organisation (OWASP). The case weighs heaviest for records that delegate an entire zone to external name servers: control then passes for every name below that zone, not just for a single host.
Three questions per DNS record
Test data is customer data
Test systems usually start as a copy: pull the database, copy the files, change the address, done. That moves orders, addresses, payment details and customer accounts into an environment where neither the update regime nor the access rules of the production system apply. The IT-Grundschutz standard is explicit here: if test data contains personal information, it must at minimum be pseudonymised, and it should be fully anonymised wherever possible (BSI, IT-Grundschutz OPS.1.1.6.A11).
In data protection terms, the copy is treated exactly like the original. Personal data may be kept in identifiable form only as long as necessary for the purposes of processing (Article 5(1)(e) GDPR), and security of processing requires technical and organisational measures appropriate to the risk – explicitly including pseudonymisation and encryption (Article 32(1) GDPR). A test system holding real order data without access restrictions meets neither. How long which data has to be kept belongs in the same discussion as backup retention.
- Remove dumps, archives and exports from the served directory and store them outside the web root
- Pseudonymise data with a personal reference before a copy is reused for testing
- Set an end date per test system and record it in the maintenance plan
- Separate test system credentials from production credentials and revoke them once the project ends
- Block metadata directories and configuration files at the server level instead of relying on protection inside the application
- Export data subject to retention obligations rather than keeping the old application running for it
- Take a backup before shutting anything down and restore it once as a trial
- Remove the DNS record after the shutdown and note the outcome in the list
What should leave the search index
A system that has been switched off does not leave the search index merely by no longer answering – and a locked preview does not leave it merely by asking for a password. The condition is stated plainly: for the noindex rule to take effect, the page or resource must not be blocked by a robots.txt file and has to be accessible to the crawler (Google Search Central). Blocking an old address in robots.txt while setting a noindex achieves the opposite: the rule does not get read in the first place.
For forgotten systems that implies a small sequence: first set the X-Robots-Tag response header with noindex, then check that the address can actually be fetched, and only afterwards restrict access or switch the system off. For addresses that disappear permanently, a redirect to the matching live page is cleaner than a block: the old address loses its own existence in the index without leaving an error page behind.
This sequence is why cleanup and monitoring indexability belong together. A noindex that lands on the production shop by accident costs visibility; a missing noindex on the preview creates duplicates. Both surface in the same measurement, provided it runs across all known hosts and not just the home page of the main domain.
Turning cleanup into a fixed date
Cleanup is not a project with an end but a recurring check. Exploitation of vulnerabilities was the starting point for 20 percent of the analysed breaches with a known access vector and has grown again (Verizon, DBIR 2025). For the exploited edge device vulnerabilities, the same analysis showed that only about 54 percent were fully remediated over the year, taking a median of 32 days (Verizon). Those figures come from maintained environments with a patch process. A forgotten system has no such curve at all – there the gap stays open until somebody switches the system off.
The date for this needs no organisation of its own. It attaches to dates that exist anyway: the quarterly review, certificate renewal, or the change freeze before peak season. The change freeze is particularly suitable because cleanup happens before it anyway, and because the quiet phase makes it obvious which systems still receive requests. In practice a fixed quarterly rhythm works well, complemented by a check after every relaunch and every project that ends with external parties involved.
The output is abridged; what matters is its structure. Every line carries three pieces of information: the name, the response and the reason for the classification. An entry without a response is just as notable as one with a response – the first stands for a target that has vanished, the second for a system that is still being served. What matters is that the check runs across the complete list and not across the hosts you keep an eye on anyway.
What the date documents
The same fields are documented for every entry: name, purpose, responsible person, software version, date of the last change, decision taken and – for locked or archived systems – a date for the next review. Those seven fields fit into one table and answer the questions that get asked in an emergency: what was reachable, who owned it, when did somebody last look.
The benefit shows outside the security question too. With a maintained list you can attribute effort, cancel accesses that no longer serve a purpose, and hand a project over in hours rather than days. In the overview of services the inventory therefore sits at the beginning of an engagement, not at the end. It is also the basis for putting a number on the scope of a maintenance contract at all.
A system without a responsible person is not a residual risk but an open door with a forgotten address.
A running order for the first pass
For the first pass a fixed order has proven itself: the DNS zone first, because it sets the frame; then the issued certificates, because they supply names missing from the zone; then web server and file system, because they show what is actually being served; the contracts last, because they reveal the remaining gaps. Only after that does each entry get its decision, and only after that does anything get switched off.
Two habits shorten the pass considerably. First: note the four fields at the moment of discovery – name, purpose, responsible person, last modification date – instead of assembling them later. Second: switch nothing off without having taken a backup and restored it once. A decommissioned system whose backup will not open creates a second building site exactly where one was just closed.
Inventory as a fixed item in the maintenance contract
Sources and studies
Related Articles
Shop Server Logs: How Long IP Addresses May Be Stored
How long may IP addresses stay in server logs? What the GDPR requires, what the five weeks from the BfDI mean, and how rotation, truncation and backups fit in.
WordPress security updates: what old branches still get
WordPress 7.1.2 closed a critical flaw and the fix was backported to 4.7 as a courtesy. What older branches receive, what they do not, and when to move up.
Discount codes in Black Week: detecting abuse early
Discount codes in Black Week: code length, a rate limit at the coupon field, alerts on failed attempts and new-customer discounts that resist multiple accounts.