How to Disable Directory Listing (Browsable Web Directories, Nessus 40984)

Browsable Web Directories (Nessus plugin 40984) means your web server returns an automatically generated file listing when someone requests a folder that has no index page. To disable directory listing, remove Indexes from Apache’s Options, set nginx autoindex off;, turn off IIS Directory Browsing, then confirm the folder URL returns 403 or 404 and rescan.

What the scanner is actually detecting

Every scanner that reports this works from the outside. It crawls the site, requests directory paths such as /uploads/ or /backup/, and flags responses that match a server-generated index: the “Index of /path” page from Apache or nginx, the IIS page with a “[To Parent Directory]” link, or Tomcat’s “Directory Listing For” page. It never reads your configuration, so the verdict is per URL, per hostname and per port.

Nessus 40984 is a summary plugin. Tenable describes it as reporting directories that other Nessus plugins found to be browsable during the web crawl, and its output lists each browsable URL. Treat that list as your work list. Tenable WAS and Burp both map the issue to CWE-548 (information exposure through directory listing).

How serious is it?

A directory listing is information disclosure, not code execution, which is why Burp rates it Information while Tenable rates it Medium. The listing does not grant access to anything that was not already downloadable; it removes the guesswork. The real risk depends on what sits in the folder. PortSwigger mentions temporary files and crash dumps, and the listings that matter typically expose things like forgotten database exports, zipped copies of the site, config.php.bak style configuration copies, logs or source code. A listing of stock icons or public images is close to harmless.

Note that turning off listings does not protect a sensitive file whose name can be guessed or is already known, so remove or relocate those files as part of the fix.

How to confirm it on the host

Request each URL from the plugin output from a machine outside the server:

curl -si http://host.example.com/uploads/ | head -n 15
curl -s http://host.example.com/uploads/ | grep -iE 'Index of|Directory Listing For|To Parent Directory'

A vulnerable folder returns 200 OK with a file index. A fixed one returns 403, 404 or a real index page. Next, find the setting that is actually loaded:

# Apache, RHEL / Rocky / AlmaLinux
grep -Rn 'Options' /etc/httpd/conf/httpd.conf /etc/httpd/conf.d/

# Apache, Debian / Ubuntu
grep -Rn 'Options' /etc/apache2/apache2.conf /etc/apache2/sites-enabled/ /etc/apache2/conf-enabled/

# .htaccess files that can switch listings back on
find /var/www -name .htaccess -exec grep -Hn 'Indexes' {} +

# nginx (nginx -T prints the full loaded configuration)
sudo nginx -T 2>/dev/null | grep -n 'autoindex'

# Tomcat
grep -n -A1 '<param-name>listings' "$CATALINA_BASE/conf/web.xml"

On IIS, query the effective setting for the flagged path, then look for web.config files that override it (adjust the path if your content is not under C:inetpub):

%windir%system32inetsrvappcmd.exe list config "Default Web Site/uploads" -section:system.webServer/directoryBrowse

Get-ChildItem -Path C:inetpub -Recurse -Filter web.config | Select-String -Pattern 'directoryBrowse'

How to fix it

Apache httpd

The Indexes option tells mod_autoindex to generate a listing when a directory has no DirectoryIndex file. Both major distribution families enable it for the default document root: RHEL-family httpd.conf and Debian’s apache2.conf ship Options Indexes FollowSymLinks.

One rule from the Apache documentation decides where the fix goes: when several Options directives apply to a directory, the most specific one wins and the others are ignored, unless every option in it carries a + or - prefix. A global Options -Indexes therefore does not override a more specific block that says Options Indexes. Edit the block that actually applies.

On RHEL, Rocky and AlmaLinux, in /etc/httpd/conf/httpd.conf inside <Directory "/var/www/html">, change the line to:

Options FollowSymLinks

The same family also ships /etc/httpd/conf.d/autoindex.conf, which sets Options Indexes MultiViews FollowSymlinks on /usr/share/httpd/icons (served as /icons/). If /icons/ is in your finding, change that line to Options MultiViews FollowSymlinks.

On Debian and Ubuntu, in /etc/apache2/apache2.conf inside <Directory /var/www/>, make the same change to Options FollowSymLinks. Then check every virtual host with its own DocumentRoot and <Directory> block.

To strip listings from one tree while keeping whatever else it inherits, use the relative form:

<Directory "/var/www/example/uploads">
    Options -Indexes
</Directory>

Do not mix prefixed and unprefixed options (for example Options -Indexes FollowSymLinks): Apache rejects that syntax and aborts at startup. Options -Indexes in an .htaccess file works only when AllowOverride permits Options; otherwise requests to that directory fail with a server error. Validate and reload:

sudo apachectl configtest && sudo systemctl reload httpd      # RHEL family
sudo apache2ctl configtest && sudo systemctl reload apache2   # Debian family

nginx

The autoindex directive defaults to off and is valid in http, server and location context. A finding on nginx therefore means someone added autoindex on; somewhere, or the listing comes from a proxied backend. Delete each unwanted autoindex on; line, or set it explicitly in the affected block:

location /downloads/ {
    autoindex off;
}

Setting off at the http level does not override an on inside a location, so fix the specific block. If nginx -T shows no autoindex on but the listing persists, fix the upstream application instead. Then:

sudo nginx -t && sudo systemctl reload nginx

IIS

The enabled attribute of <directoryBrowse> defaults to false, so a listing means it was switched on at the server, site, application or folder level. In IIS Manager, select that node, open Directory Browsing and click Disable in the Actions pane. From an elevated prompt, per site or server wide:

%windir%system32inetsrvappcmd.exe set config "Default Web Site" -section:system.webServer/directoryBrowse /enabled:"False"
%windir%system32inetsrvappcmd.exe set config -section:system.webServer/directoryBrowse /enabled:"False" /commit:apphost

The equivalent web.config entry:

<configuration>
  <system.webServer>
    <directoryBrowse enabled="false" />
  </system.webServer>
</configuration>

A web.config deeper in the tree that sets enabled="true" still wins for its own path, so remove or correct those files too. Once fixed, IIS answers folder requests without a default document with 403.14 (Directory listing denied).

Apache Tomcat

Listings come from the DefaultServlet’s listings parameter in $CATALINA_BASE/conf/web.xml, which defaults to false. Set it back to false, check each application’s WEB-INF/web.xml and WEB-INF/tomcat-web.xml for an override, and restart Tomcat. The Tomcat documentation also warns that listings of large directories are expensive and can consume significant server resources.

Folders that must stay reachable

• Add an index page (Apache DirectoryIndex, nginx index, IIS Default Document) so the folder URL shows content you chose.
• Deny folders that should never be served, for example Require all denied in an Apache <Directory> block, or deny all; in an nginx location.
• Move backups, exports and dumps out of the document root, and delete what nobody needs.

How to verify the fix and rescan

1. Rerun the curl commands against every URL in the finding, on every hostname, virtual host and port listed.
2. Test through the path the scanner used: if it scanned a public VIP or CDN hostname, test that, not only the backend node.
3. Confirm each folder returns 403, 404 or a real index page, and that the grep for listing markers returns nothing.
4. Rescan with the same policy that produced the finding. Because plugin 40984 reports what other Nessus web plugins discovered, a trimmed policy that skips the web crawl can come back clean without testing anything. For Tenable WAS, Burp and ZAP, rerun the crawl and audit over the same scope.

What can break and how to roll back

The usual casualties are people or scripts that browse or scrape a listing, such as an internal download share or a build artifact folder. Give that one path an index page or a documented exception rather than re-enabling listings server wide. The other risk is configuration mistakes: mixed +/- syntax stops Apache from starting (configtest catches it), and Options in an .htaccess without the matching AllowOverride breaks that directory.

Back up every file before editing. To roll back:

• Apache: restore Indexes in the specific <Directory> block, run configtest and reload.
• nginx: set autoindex on; in that location only, run nginx -t and reload.
• IIS: click Enable under Directory Browsing, or rerun appcmd with /enabled:"True".
• Tomcat: restore the previous web.xml and restart.

Common false positive reasons

• Intentional listing. A public mirror or download area is supposed to list files. Record it as an accepted risk after checking that nothing sensitive is in it.
• Look-alike pages. An application file browser or a hand-written HTML index can resemble a server-generated listing.
• Catch-all responses. Applications that return 200 for any path can confuse crawl-based checks. This and other patterns are covered in common causes of vulnerability scanner false positives.
• Wrong layer. The listing came from a CDN, reverse proxy or backend rather than the server you changed. See how a WAF or proxy changes what a web scan sees.
• Wrong service. The port belongs to something else, such as an appliance UI or a forgotten python3 -m http.server, which lists directories by design.
• Default virtual host or stale data. A scan by IP address lands on the default site, or the report predates your change.

FAQ

Is directory listing a vulnerability on its own?

It is an information exposure. Its severity is set by what the folder contains, which is why scanners disagree on the rating.

Should the folder return 403 or 404?

Either clears the finding. Apache and nginx return 403 by default once listings are off, and IIS returns 403.14. A 404 hides that the folder exists; in nginx, return 404; in the location does that.

Does adding the folder to robots.txt fix it?

No. Robots.txt only asks well-behaved crawlers to skip a path. It does not block requests, and it publishes the path names to anyone who reads it.

Why is /icons/ flagged on a fresh RHEL-family server?

The stock autoindex.conf enables Indexes on the icons alias. The content is harmless Apache artwork, but the one-word change above clears the finding.

Tracking this finding across many hosts

Directory listing is reported per URL and often by several tools at once. SITEY, a self-hosted vulnerability management platform, imports findings from 16 scanners and merges duplicates within each scanner (not across scanners), so the same folder can appear once from Nessus and once from a DAST tool. Nessus and Burp findings can be re-tested individually after the change, and AI triage can suggest likely false positives with evidence for a human to decide.

Sources

• Tenable: Browsable Web Directories (Nessus plugin 40984)
• PortSwigger: Directory listing (issue definition)
• Apache HTTP Server 2.4 documentation: Options directive
• nginx documentation: ngx_http_autoindex_module
• Microsoft Learn: Directory Browse <directoryBrowse>