Directory listing enabled

Backup copies of files, which frequently carry a suffix the server no longer recognises and therefore serves as text.

Database exports and archives left after a migration.

Editor artefacts and swap files, which contain fragments of whatever was being edited.

Documents uploaded to a directory as a quick way to share them with one person.

Older versions of assets, which is harmless, and the file sitting next to them that is not.

Discovery does not only happen through links: a listing names every file directly.

A directory whose listing was fetched once can be indexed, and the files then appear in search results.

So the protection a file had was that nobody knew the name, and the listing removes exactly that.

The same reasoning applies to a file whose name is guessable, which is why a backup named after the original is a poor hiding place regardless.

A default server configuration with listings on, unchanged after installation.

A virtual host added later without the directives the main one carries.

An asset directory served directly by the web server rather than through the application, where the application's own routing never applies.

A static hosting platform whose default behaviour is to list, which is deliberate for file distribution and surprising for a website.

An upload directory served from the document root, which is the highest-consequence version of this.

Disable listings in the server configuration, which is one directive on every common server.

Do it globally rather than per directory, so a directory added later inherits it.

Serve an index file where a directory should have one, and let the server refuse where it should not.

Move anything not meant to be public out of the document root entirely, rather than relying on the listing being off.

Audit what was in the listed directories, since disabling the listing does not un-publish what was already fetched or indexed.

Treat credentials in any exposed file as compromised and rotate them.

Check whether the paths are in a search index and request removal where they are.

Check your access logs for requests to the listed directory, which shows whether anything was actually fetched.

Remove the files rather than only hiding the listing, because a guessable name remains guessable.

Request a directory path directly — a path ending in a slash with no index file behind it.

A listing of filenames is the defect; a 403 or a 404 is the server behaving correctly.

Try the asset directories, the upload directory and anything served outside the application's routing.

Search a search engine for your domain restricted to the index-of pattern, which finds listings that were already crawled.

Check subdomains separately, since they frequently run different configurations.

`exposure.assets.coverage` reports how much of the public asset surface was really inspected, which frames every finding here.

`exposure.secrets.private` and `exposure.internal.paths` report credentials and server paths found in served files.

`exposure.sourcemap.public` reports publicly accessible source maps, which are a related category of file nobody meant to publish.

`quality.security_txt` and `exposure.well_known.change_password` cover the files that are meant to be at conventional paths, which is the opposite case.

Nothing is enumerated: only paths the site references or that are conventional are requested.

Some files are meant to be publicly fetchable at a fixed location: a robots file, a sitemap, a security contact, a web app manifest.

Those are published deliberately and are not what this problem is about, which is worth stating because a listing and a conventional file can sit in the same directory.

The well-known directory in particular is designed to be requested directly, and a listing of it is still a listing.

So the fix is disabling listings rather than blocking directories, since blocking would break the files that are supposed to answer.

A robots directive disallowing a directory does not prevent access to it either — it asks crawlers not to fetch, and the listing remains available to anyone who requests it.