Directory structure visible

An attacker who does not know which files sit on a server has to guess. With directory listing enabled, that is unnecessary: the web server supplies the table of contents itself. That is rarely serious because of the list itself, and often serious because of what has been left lying in such a folder over the years. The consequences reach further than an untidy impression.

What is directory listing?

Directory listing is the behaviour where a web server, on a request for a folder without an index file, returns an overview of its contents instead of an error. You then see a list of filenames, sizes and modification dates, exactly as a file manager would show.

It is default behaviour that was once useful for simple file archives, and that is still enabled in some server configurations. On a modern web application it is virtually never desirable.

The effect resembles the difference between a closed archive cabinet and an open shelf. In both cases someone who knows exactly what they are looking for might find it. But with an open shelf they need to know nothing: they walk past and read the spines.

What does a directory listing reveal?

Vulnerable:

GET /uploads/ HTTP/1.1
Host: portal.example

HTTP/1.1 200 OK

Index of /uploads

  Name                              Modified          Size
  ../
  customer-list-2024.xlsx           2024-11-03 14:22   842K
  config.php.bak                    2023-06-12 09:41   4.1K
  database-dump.sql.gz              2025-02-18 03:00    64M
  test-invoice.pdf                  2025-07-29 16:05   112K
  .env.old                          2023-01-08 11:33   1.2K

The list itself is not the problem; the contents are. There is a customer file, a database export, a backup of a configuration file and an old environment file. None of those was ever deliberately published; they ended up there because the folder was convenient. Without listing, an attacker would have had to guess the names, and nobody guesses database-dump.sql.gz with that exact name. Now it is simply there.

Safe:

# Disabling at server level applies to everything, including new folders
autoindex off;

# And the files that should not be there in the first place
location ~ \.(bak|old|orig|sql|gz|env|log)$ {
    deny all;
    return 404;
}

# Apache
Options -Indexes

Disabling it is one line, and it applies immediately to every folder, including folders created later. The additional block on file extensions is a safety net in case something does end up where it should not.

The structural measure goes beyond configuration: files that should not be public do not belong in the web root. Keep exports, backups and user-uploaded files outside the published folder and serve them through a route that authorises first.

What is the impact of a visible directory structure?

The severity runs from low to high, and that spread is justified here: it is determined entirely by what sits in the folder. If it holds only images that are already public, little is wrong.

The risk arises over time. Folders created for a clear purpose fill up with whatever was put there along the way: an export for a colleague, a backup just in case, a test file from a migration. Each of those was made for a good reason and nobody thought to remove them. Directory listing makes that entire collection visible in one request.

There is also the reconnaissance value. Even without sensitive files, the list reveals how your application is built: which components exist, which filenames are used, when work was last done. That makes targeted follow-up attempts considerably more effective, for instance when looking for files in other folders.

How do you detect a visible directory structure?

A tester requests the folders known from the application, the paths images, stylesheets and documents are loaded from, and checks whether a list appears instead of an error. Beyond that they search using a list of common folder names: uploads, backup, temp, old, export, logs, admin, test.

If a listing is found, attention shifts to the contents: files with extensions pointing to backups or exports, files with a recent modification date, and files that stand out by their size. They also check whether listing is only on for some folders, which suggests protection is arranged per folder rather than centrally, a situation that will go wrong again at the next addition. AssistSec combines this with a broader search for unlinked files, because disabling the listing does not remove the files themselves and those remain directly retrievable.

How do you prevent a visible directory structure?

• Disable directory listing at server level, so the setting applies to all folders.
• Keep backups, exports and log files outside the published folder.
• Serve user-supplied files through a route that authorises first.
• Block extensions pointing to backups and exports as an additional safety net.
• Check the settings of your object storage separately; they are independent of your web server.
• Do not rely on an empty index file; that hides the list but does not fix the configuration.
• Periodically clean up what actually sits in the web root, rather than what should be there.
• Repeat the check after a server migration, because default configurations return then.