Directory Listing and Exposed Backup Files Guide: find, fix and prevent web root leaks

A web server that lists its directories, or a web root that still holds last month's database dump, gives away data and credentials to anyone who asks for the right URL. Open indexes ("Index of /"), forgotten .sql and .zip archives, editor swap files and .env files are among the oldest web exposures, and they keep appearing because they are created by everyday admin work rather than by code. This guide covers how directory listings and stray backup files arise on Apache, NGINX and IIS, how to find them on your own estate, how to fix and prevent them, and how to respond when one was public. It is for web and platform engineers, application security teams and vulnerability managers.

Key takeaways

• Two separate weaknesses travel together. CWE-548 covers exposure through directory listing and CWE-530 covers backup files reachable by unauthorised users; a listing simply makes the backup easy to find.
• Listings are off by default on modern servers. NGINX autoindex defaults to off and IIS directoryBrowse defaults to false, so a live listing usually means someone turned it on or a package did.
• Hiding a file is not protecting it. Turning off the listing, IndexIgnore and robots.txt all leave the file downloadable by anyone who guesses the name.
• Backups belong outside the web root. OWASP and MITRE CWE both point to policy and configuration management: no in-place editing on production, no archives or dumps in served paths.
• An exposed file with secrets is an incident. Rotate every credential in it, check access logs for downloads, then remove the file and its search engine copies.

How directory listings and stray files happen

When a request ends in a directory and no index file is present, a web server can either refuse or generate a list of the directory's contents. Apache separates the two jobs: mod_dir serves the file named by DirectoryIndex (usually index.html), and mod_autoindex generates a listing when there is none, but only if Options +Indexes is set for that directory. NGINX's ngx_http_autoindex_module handles requests ending in a slash when the index module cannot find an index file, and only when autoindex is on. IIS uses the system.webServer/directoryBrowse element.

Backup and unreferenced files arise from ordinary work. OWASP WSTG-CONF-04 lists the main sources:

• Editor artefacts: automatic backups such as a tilde-suffixed copy, and swap files left after a session on the server.
• Manual copies: config.php.old, login.asp.bak, or a Windows "Copy of" file kept "just in case".
• Archives: site.zip, www.tar.gz or a database dump created before a migration and never moved.
• Data, logs and configuration written into web-accessible directories by the application or an admin.
• File system snapshots that appear as reachable directories under the web root.

Renamed scripts are especially dangerous: login.asp.old is no longer executed by the server, so it is returned as plain text, disclosing source code, connection strings and logic. MITRE's CWE-530 entry gives a modern example, CVE-2024-7315, in which a WordPress plugin generated backup file names with insufficient randomness so attackers could guess and download them.

Server settings that control listings

Apache's mod_autoindex documentation is explicit that IndexIgnore only removes names from the listing; the files remain reachable. Use access control (Require directives, FilesMatch blocks) to deny sensitive patterns. See the Apache HTTP Server Hardening Guide, the NGINX Security Hardening Guide and the IIS Hardening Guide for the rest of each server's baseline.

High-risk file types to hunt for

Where identity fits

The damage from a stray file is mostly measured in the machine credentials it contains: database accounts, cloud access keys, SMTP and payment API keys, CI tokens. Those non-human identities rarely have MFA, are often shared across environments and are seldom rotated, so a single downloaded .env file can unlock production. The 230 Million AWS Cloud Environments Campaign 2024 began with IAM keys found in exposed .env files, which the attackers used to create new roles with administrator access, and the Indian Government Breach 2021 involved exposed .git and .env files that leaked credential pairs. Keep secrets out of files in the web root altogether by injecting them at runtime from a secrets manager. See the OWASP NHI Top 10 NHI2 Secret Leakage Guide.

Finding exposures on your own estate

1. Inventory the servers. Start from your attack surface inventory: every internet-facing host, virtual host and CDN origin, including staging and acquired sites. See the Attack Surface Management Guide.
2. Review configuration (white box). Search server configs and code repositories for Options Indexes or Options All, autoindex on and directoryBrowse enabled="true", including .htaccess and nested web.config files.
3. Scan the file systems (grey box). OWASP recommends scripted searches of served directories for backup-style extensions, run periodically. List anything matching the patterns above under each document root, plus any file larger than an agreed size.
4. Test from outside (black box). With authorisation, request directories without index files and check for listings, and run a curated wordlist of backup names and extensions against your own hosts using your vulnerability scanner or DAST tool. This is the same activity ATT&CK describes as T1595.003 Wordlist Scanning, so schedule it and tell the SOC.
5. Check search engines and archives. Query for intitle:"index of" and backup file types scoped to your domains, and look at historical copies. See the Search Engine Dorking for Defenders Guide.
6. Record and assign. Every finding gets an owner, a data classification and a due date in the vulnerability management system.

Fixing and preventing

• Disable listings globally: set Options -Indexes in the main Apache config and restrict AllowOverride so .htaccess cannot turn it back on; confirm no autoindex on in NGINX; set directoryBrowse to false at server level in IIS and remove the feature where not required.
• Deny sensitive patterns: add server rules returning 403 or 404 for dotfiles (except /.well-known/), version control folders and backup extensions, so a forgotten file is still not served.
• Move data out of the web root: logs, uploads that need no direct URL, configuration and dumps go to paths the server never serves. OWASP lists this as a core remediation.
• Ban in-place editing on production: deploy through a pipeline that builds a clean artefact, so editor files and manual copies never reach the server.
• Build an artefact allow list: the deployment package contains only the files the application needs; fail the pipeline if it contains .sql, .zip, .env or .git content.
• Govern backups: write database and site backups to dedicated storage with access control and encryption, never to a served folder. MITRE CWE-530 recommends a policy prohibiting source code backups in the web root.
• Use random, unguessable names only as a secondary measure: CVE-2024-7315 shows predictable backup names are found; randomness does not replace access control.

Rolling out the fix safely

1. Inventory which sites rely on a listing for a real purpose (public download mirrors, for example) and document those exceptions.
2. Apply the change in staging and run the application's functional tests; a broken page usually means a missing index file.
3. Deploy to a pilot group of low-risk sites, watching for new 403 responses on directory URLs in the access logs.
4. Roll out to the remaining estate; roll back by reverting the configuration change for the affected site only, not globally.
5. Add a configuration compliance check so drift is detected.

Choosing controls for your environment

The right mix depends on how many sites you run and who changes them.

• A handful of sites, one team: a hardened server configuration, a deny rule for sensitive patterns and a monthly file-system scan are enough. The main risk is the admin who makes a quick copy on the server, so the policy against in-place editing matters most.
• Shared hosting or many CMS sites: owners can upload files and install backup plugins, so server-level deny rules and scheduled external checks carry more weight than configuration review. Block .htaccess overrides of Options where the platform allows.
• Containerised or pipeline-deployed applications: immutable images make stray files rarer, so put the effort into the build: an artefact allow list and a pipeline check that rejects archives, dumps and dotfiles. Scan running containers less often.
• Legitimate public file listings: download mirrors and open data portals may need listings. Serve them from a dedicated host or bucket that holds nothing else, never from an application's web root, and review the contents on each publication.

Deny rules versus moving files: a deny rule is quick and catches mistakes, but it is a safety net. Moving data, logs and backups out of the web root removes the exposure entirely and should be the target state; use both while the migration runs.

When an exposure is found

Treat a publicly reachable dump, archive or config file as a potential breach until logs say otherwise.

1. Preserve evidence: copy the file, note its path, timestamps and permissions, and secure web access logs for the full period it existed.
2. Rotate every credential in the file before removing it, starting with cloud and database accounts.
3. Remove the file and close the listing, then confirm with a fresh request.
4. Search access logs for successful (200) responses to the file's URL and for listing requests to its directory, noting source IPs and user agents.
5. Assess whether personal data was exposed. Under UK and EU GDPR Article 33, a personal data breach must be notified to the supervisory authority without undue delay and, where feasible, not later than 72 hours after becoming aware of it, unless it is unlikely to result in a risk to individuals.
6. Remove search engine copies (see the dorking guide) and fix the upstream process that created the file.

Detection and measurement

Alert on requests for backup extensions, dotfiles and version control paths, on bursts of 404s that look like wordlist scanning, and on any 200 response to those patterns, which means a file actually exists. Metrics:

• Hosts with listings enabled: target zero outside documented exceptions.
• Sensitive files in web roots: count per scan, trending to zero.
• Time to remediate: median hours from finding to removal, with credential findings treated as urgent.
• Pipeline blocks: deployments stopped for disallowed files, showing prevention is working.
• Recurrence: repeat findings on the same host within 90 days.

Common failure patterns

• Relying on robots.txt. Google states robots.txt is not a mechanism for keeping a page out of search, and listing /backup/ there advertises it.
• Turning off the listing but leaving the files. Wordlist scanning finds backup.zip and db.sql without any listing.
• Nested overrides. A single .htaccess or subfolder web.config re-enables browsing below a hardened server configuration.
• Deleting without rotating. Exposed .env keys are harvested at scale, as the 230 Million AWS Cloud Environments Campaign 2024 shows.
• Forgetting non-production. Staging hosts often hold copies of production data with the weakest configuration.
• Backup plugins writing to the web root. CMS backup tools that store archives under a served uploads path with guessable names.

Framework mapping

Practitioner checklist

• Disable directory listings at server level on Apache, NGINX and IIS, and block overrides.
• Deny dotfiles, version control folders and backup extensions with server rules.
• Keep logs, configuration, dumps and archives outside every web root.
• Deploy only pipeline-built artefacts and fail builds containing .sql, .zip, .env or .git content.
• Scan document roots for backup-style files on a schedule and after each change window.
• Run authorised external wordlist checks against your own hosts and inform the SOC.
• Rotate credentials before removing any exposed file, and review access logs for downloads.
• Assess GDPR Article 33 notification when personal data was in the file.
• Track hosts with listings, sensitive files found and time to remediate monthly.

Standards and references

• MITRE: CWE-548 Exposure of Information Through Directory Listing
• MITRE: CWE-530 Exposure of Backup File to an Unauthorized Control Sphere
• OWASP: WSTG-CONF-04 Review Old Backup and Unreferenced Files for Sensitive Information
• Apache Software Foundation: Apache Module mod_autoindex
• NGINX: Module ngx_http_autoindex_module
• Microsoft Learn: Directory Browse directoryBrowse
• Google Search Central: Introduction to robots.txt
• EUR-Lex: Regulation (EU) 2016/679 (GDPR), Article 33

Related NHI Mgmt Group resources: Exposed .git Directory Response · Search Engine Dorking for Defenders Guide · Attack Surface Management Guide · Apache HTTP Server Hardening Guide