The fix, in one snippet
autoindex off; # nginx
Options -Indexes # ApacheIllustrative values. Change the paths, hostnames and options to match your own site before using it.
The sections below explain what is tested, why it matters and the alternatives.
What we test
Scan.now requests a short list of directories that commonly exist and commonly lack an index page: /images/, /img/, /uploads/, /assets/, /static/, /files/, /backup/, /includes/, /css/, /js/, and for WordPress sites /wp-content/uploads/ and /wp-includes/. A finding requires a 200 response whose body carries a server-generated listing signature: <title>Index of / from Apache's mod_autoindex, <h1>Index of from nginx's autoindex module, [To Parent Directory] from IIS, or Directory Listing For from Tomcat. The report names the directory and the server flavour. Scan.now reads only the first response; it does not crawl the listing. Rated medium because the impact depends entirely on what the directory contains, which is usually more than its owner remembers.
Why it matters
A listing removes the only thing that was hiding unlinked files. Upload directories reveal documents users submitted in confidence, invoices, identity scans, or private images, all of them now enumerable and indexable by search engines. Asset and include directories reveal the application's structure, old versions of scripts and backup copies (config.php.old) that would otherwise take guesswork to find. A WordPress uploads listing exposes every media file ever attached to a draft or private post. Listings also help an attacker date the software by file timestamps. None of this is an exploit in itself, but it converts "security by obscurity" into no security at all and routinely leads directly to the credential and backup exposures covered by exposed-backup-files. The exposed files guide gives more context.
How to fix it
Turn off automatic indexes and, where the directory must be reachable, give it an index page. nginx (autoindex is off by default; look for a stray autoindex on in a location block):
autoindex off;Apache, in the vhost or a .htaccess file:
Options -IndexesIIS, in web.config:
<system.webServer>
<directoryBrowse enabled="false" />
</system.webServer>Express: express.static does not list directories; if you see listings, remove the serve-index middleware. Tomcat: set listings to false for the default servlet in conf/web.xml. For directories holding user uploads, go further and move them outside the document root, serving files through an authenticated handler that checks who may see what. Cloudflare cannot disable listings at the origin, though a WAF rule can block direct requests to /uploads/ with no filename as a stopgap.
Where this fits
Directory listing enabled is check 5 of 14 that the website vulnerability scanner runs under exposed files and information disclosure, ordered the way they are worth fixing. That ordering is the point: Fixing this one while the check above it still fails buys less than it looks like.
Fix this one first
Above it in the same category sits Exposed phpinfo() page (high), where a phpinfo() page is publicly reachable. An attacker who has that does not need this, so it is the better use of the same hour.
What fixing this still leaves open
Directory listing enabled closes one route in. Immediately below it: Exposed server status page, where a server status page (Apache mod_status, nginx stub_status or PHP-FPM status) is reachable from the internet, revealing live requests, client IPs, internal hostnames and load details; WordPress user enumeration via REST API, where the WordPress REST API or author archives reveal account usernames to anonymous visitors, giving attackers half of each credential pair before they start guessing passwords; WordPress xmlrpc.php enabled, where the WordPress XML-RPC endpoint at /xmlrpc.php is enabled.
Found in the same scan
The website vulnerability scanner reports this alongside checks from other categories that are at least as serious, including Certificate chain and hostname validation, where the certificate presented for this hostname did not validate: The chain does not reach a trusted root, an intermediate is missing, the name does not match, or the certificate is self-signed or expired, and HTTPS is available, where the site could not be reached over HTTPS on port 443, or the TLS handshake failed. A single run of website vulnerability scanner answers all of them at once.
The first few lines
You are a senior web engineer. I ran a security and SEO scanner against my site and it reported the finding below. Fix it properly rather than suppressing the symptom.
Finding: Directory listing enabled (medium severity)
Scanner check id: directory-listingThe rest of this prompt names the pages and line numbers we found the problem on, the configuration to change, and the constraints a good answer has to respect. It is free, it just needs an account so the work is not scraped wholesale.
Sign in with GoogleSigning in is free and takes one click. We store your email address and nothing else.
