Misconfiguration
Directory Listing Enabled
Directory listing is enabled when a web server returns an auto-generated index of a folder's contents instead of a page, exposing file and folder names such as backups, configs, and source code to anyone who requests the path.
A blank-looking URL that quietly answers with a page titled "Index of /" is one of the easiest wins an attacker ever gets. No exploit, no payload, no authentication bypass: the web server volunteers a clickable map of everything sitting in that folder, including the files nobody meant to publish. What looks like an empty directory is often a directory full of secrets that were never linked from anywhere.
What it is
Directory listing (also called directory indexing or autoindex) is a web server behavior that, when a requested folder contains no index file (such as index.html or index.php), generates and returns an HTML page enumerating every file and subfolder in that directory. It is controlled by server settings: Apache's mod_autoindex with Options +Indexes, nginx's autoindex on, IIS's Directory Browsing feature, and equivalents in Tomcat and other servers. The feature is sometimes intentional for file-sharing endpoints, but on application servers it is almost always an oversight left over from defaults or copied configuration. OWASP classifies it under A05:2021 Security Misconfiguration and tests for it under WSTG-CONF-04, noting it is the most obvious way a misconfigured server discloses unreferenced pages.
An enabled directory listing turns reconnaissance from guesswork into a guided tour. The files most damaging to lose are exactly the ones that end up in browsable folders by accident: database backups (.sql, .bak), version-control or editor artifacts, .env files holding API keys and credentials, configuration files with connection strings, and source code that reveals internal logic an attacker can study offline. OWASP's own A05 scenario describes an attacker who finds directory listing enabled, downloads compiled Java classes, and decompiles them to read the application's source. The practical stakes are credential theft, full source disclosure, and the staging data needed for a deeper breach or ransomware foothold, all from information you handed over for free. Because the listing also reveals exact filenames and timestamps, it shortcuts the brute-force enumeration step attackers would otherwise need, compressing the time between discovery and exploitation.
At a glance
How attackers find and exploit it
- Crawl the target's web properties and probe directory paths (such as /backup/, /uploads/, /assets/, /old/, /.git/) by removing trailing filenames from known URLs to see which folders respond with an index page.
- Fingerprint responses for the auto-index signature: an HTML body beginning with "Index of /" and a server-generated table of filenames, sizes, and last-modified dates.
- Run automated content-discovery tools such as gobuster, feroxbuster, dirb, or ffuf with directory wordlists to enumerate folders at scale and flag any that return a listing rather than a 403 or 404.
- Read the exposed listing to harvest high-value targets: download backups (.sql, .zip, .tar.gz, .bak), configuration files (.env, web.config, settings.py), and source files that reveal logic, hard-coded secrets, and internal hostnames.
- Decompile or grep the recovered artifacts for credentials, API keys, database connection strings, and private endpoints, then pivot using those secrets to authenticate to internal services, cloud accounts, or databases.
- Use disclosed filenames and directory structure to map the application, find unreferenced admin panels or legacy versions, and chain the information into a more targeted attack such as exploiting a known CVE in a discovered component.
How to detect it on your surface
- Inventory every web-facing host, virtual host, and path, then request common directory paths without a trailing filename and inspect whether the server returns a generated index instead of a 403, 404, or redirect.
- Crawl your own sites with a spider that follows links and also tests parent directories of every discovered asset (for example, request /assets/ when /assets/app.js is found) to surface folders that index their contents.
- Run a content-discovery scan against your own surface with a directory wordlist and flag any 200 OK response whose body matches the auto-index fingerprint.
- Audit web server configuration directly: check Apache for Options +Indexes and mod_autoindex, nginx for autoindex on, IIS for Directory Browsing enabled, and any reverse-proxy or CDN that may add it.
- Check object-storage static hosting (such as S3 website endpoints and bucket index behaviors) and developer servers (python -m http.server, Node static servers) that default to listing, since these often sit outside the main web server config review.
Detection signals
- Response body opens with the heading "Index of /<path>" and renders an HTML table of file names, sizes, and last-modified timestamps.
- HTTP 200 OK returned for a path ending in a slash that contains no index file, instead of a 403 Forbidden or 404 Not Found.
- Apache-style listings include a "Parent Directory" link and sortable column headers (Name, Last modified, Size, Description) generated by mod_autoindex.
- nginx listings show a <pre> block with hyperlinked entries and right-aligned sizes; IIS listings present a plain table with the server's date/time format and "[To Parent Directory]".
- Server response headers expose the web server and version (Server: Apache/2.4.x, nginx/1.x, Microsoft-IIS/10.0) alongside the index page, confirming the generating engine.
Validate before you report
- Confirm the response is a server-generated listing, not a legitimate application page or a custom index.html that merely resembles one, by verifying the auto-index markup signature and the absence of an application template.
- Request at least one listed file directly and confirm it returns 200 OK with real content, proving the listed entries are actually retrievable and not stale references behind access control.
- Assess the sensitivity of what is exposed by reviewing the listed filenames for backups, .env or config files, source code, archives, or version-control directories, since a folder of public images is materially different from one holding credentials.
- Verify reachability from the public internet (not just an internal network) and capture the exact URL, HTTP status, response headers, and a snapshot of the listing as evidence of a true positive.
- Determine scope by checking whether the listing is isolated to one folder or recursive into subdirectories that also index, which changes both severity and the remediation surface.
What looks like this but isn't
- A hand-built file-browser or download portal that intentionally publishes a directory of files (for example, a public software-release or documentation mirror) is by design, not a misconfiguration; confirm intent before flagging.
- A custom index.html or single-page-app catch-all that lists items as application content is not auto-indexing; verify the markup is application-generated rather than the server's autoindex output.
- An HTTP 403 or 404 returned with a styled error page that happens to mention "directory" is not a listing; confirm an actual enumerable table of retrievable files exists before treating it as exposed.
Remediation
- Disable directory listing at the web server: set Options -Indexes in Apache (httpd.conf or .htaccess) and disable mod_autoindex, set autoindex off in nginx, and turn off Directory Browsing in IIS via the management console or web.config.
- Place a default index file (index.html or an empty index page) or an explicit deny rule in directories that have no business returning content, so a request resolves to a benign page or a 403/404 instead of a listing.
- Remove sensitive artifacts from web-accessible paths entirely: backups, database dumps, .env files, archives, and version-control directories should never live under the document root regardless of listing status.
- Apply deny-by-default access controls for known-sensitive paths (deny rules or location blocks for .git, .env, .bak, .sql, .old, and backup folders) so even direct requests to listed files are blocked.
- Harden the base image and configuration management so the secure setting is the default across all environments, and bake the disabled-listing state into infrastructure-as-code templates rather than fixing servers one at a time.
- Re-scan the affected hosts after the change to confirm the directories now return 403 or 404 and no listing is regenerated, then verify object-storage and developer-server endpoints are covered too.
Operational checklist
- Enforce directory listing disabled as a default in all server build images, container base images, and infrastructure-as-code so new deployments inherit the secure setting automatically.
- Keep backups, configuration, source archives, and secrets outside the web document root, and store secrets in a dedicated secrets manager rather than files on the web tier.
- Run periodic content-discovery and crawl-based scans against the external surface to catch newly introduced listable directories before attackers do.
- Add an automated check to CI/CD or configuration audits that fails a deploy if autoindex, Options +Indexes, or IIS Directory Browsing is enabled on web-facing hosts.
- Maintain an authoritative inventory of internet-facing web hosts and virtual hosts so every property, including forgotten staging and legacy sites, is covered by the same listing policy.
- Review object-storage static hosting and ad hoc developer file servers on the same schedule, since these commonly default to listing and escape the main web server review.
What to do next
Directory listing is a misconfiguration you can close today, and the cost of leaving it open is measured in the files you would least want a stranger to download. If even one internet-facing folder is answering with "Index of /", the fastest concrete step is to disable autoindex on that host, pull any backups or config files out of the document root, and re-scan to confirm the path now returns 403 or 404. Treat it as urgent precisely because it is cheap to fix and cheap for an attacker to find.
Each guide is written by our team, reviewed by a named security contributor, and cited against primary sources such as OWASP, CISA, NIST, and MITRE. We update pages when the underlying guidance changes. See our contributors and company.
FAQs.
Is directory listing a vulnerability or just an information leak?
What does the "Index of /" page actually mean?
How do I disable directory listing on Apache, nginx, and IIS?
Why is directory listing dangerous if the files aren't linked anywhere?
How does Legba Adversary handle Directory Listing Enabled?
References
- 01
- 02
- 03
- 04
Weakness references (CWE)
Keep exploring
- Legba AdversaryValidated external attack surface, mapped in minutes.
- Exposure libraryBrowse finding types Adversary discovers and validates.
- Exposed API keys scannerFind and validate leaked secrets across your surface.
- EASM glossaryPlain-language explainers for attack-surface terms.
- Browser threat playbooksHow modern attacks start in the browser.
