CWE-548, Exposure of Information Through Directory Listing, happens when a product inappropriately exposes a directory listing with an index of all the resources in the directory. The record applies to any language and platform, which fits: this is a web server setting, not a coding mistake.
How it happens
Ask a web server for a folder, such as /uploads/, and it has to decide what to return. If the folder has a default page, it serves that. If not, and automatic listings are on, it builds a page that lists every file inside.
That is a convenience feature, and on a development machine it is harmless. On a production server it turns a folder into a catalog. Files that were never linked from any page become one click away.
The risk grows with age. Folders collect old exports, backup copies, logs and test files, and nobody remembers they are there. A listing makes the forgotten ones easy to see. If you have read our guide to exposed backup files, you can see how the two weaknesses feed each other.
MITRE lists one observed case: CVE-2023-37599, where a web interface was configured to allow directory listing of a module path (Gold entry).
What an attacker gains
MITRE lists reading files or directories as the confidentiality impact. Exposing a directory's contents can give an attacker access to source code, or useful information for devising exploits, such as the creation times of files.
The listing does not break any lock by itself. It removes the need to guess. Instead of trying filenames, the attacker reads the names, picks the interesting ones, and downloads them.
How to find it
- Request the folders under your web root, especially upload, media, static, backup and log paths, and see whether a file index comes back.
- Look for the telltale page title "Index of" in responses.
- Check web server and framework configuration for listing or autoindex options.
- Run a dynamic scan of your site. Crawlers and scanners check for open indexes as a matter of course.
- MITRE notes that static analysis can find some instances of this weakness, for example in configuration files.
How to fix it
MITRE's recommendations, as design and configuration work: restrict access to important directories and files by adopting a need-to-know requirement for both the document root and the server root, and turn off features such as automatic directory listings that could expose private files and provide information an attacker could use.
In steps:
- Turn listings off in the web server configuration.
- Place a default page in folders that must stay reachable, or return an error for them.
- Keep private files outside the document root.
- Review what is under the document root and remove what does not need to be public.
Examples for two common servers:
# Apache
Options -Indexes
# nginx
autoindex off;
After the change, request the folder again and confirm you get an error or a page rather than an index.
Try it yourself
This demo walks through a dynamic scan of a web application, including the kind of finding an open directory produces.
Click through it at your own pace, or open it full screen.
Quick check
Turning off listings stops people browsing a folder. Does it protect the files inside?
No. Anyone who knows or guesses a filename can still request it. Listings off hides the index only. Sensitive files should not be under the document root at all.
What does a creation time tell an attacker?
MITRE gives this as an example of useful information a listing exposes. Dates can show which files are old, which are recent, and which look like leftovers.
