Directory Browsing Check: How to Test and Disable It

What is directory browsing?

When a visitor requests a folder such as /uploads/, the server first looks for a default index file. On Apache that name comes from the DirectoryIndex directive, usually index.html or index.php. If none exists and indexing is allowed, the server writes a page of its own that lists every file and subfolder.

You will meet the feature as directory listing, directory indexing, open directory, autoindex or the Index of page. The modules behind it are mod_autoindex on Apache HTTP Server, ngx_http_autoindex_module on Nginx and the directoryBrowse element on Microsoft IIS.

Defaults differ, so test instead of assuming. Nginx and IIS ship with listing off, and Apache's core Options default is only FollowSymlinks, yet many hosting images and sample configs add Indexes.

It is a setting, not a bug, and public download mirrors use it on purpose. To enable it deliberately, flip the same switch (Options +Indexes, autoindex on or directoryBrowse enabled="true") for one download folder only. Directory traversal is a different attack that escapes the web root with ../ paths.

Why directory browsing is a security risk

A listing is harmless on its own. What hurts is the content. A forgotten file used to be protected only by the fact that nobody knew its name, and a listing prints that name for every visitor. A backup in the web root is a small mistake until a listing publishes it.

A fictional example shows what a careless folder gives away.

Index of /backup

db_dump_march.sql       2026-03-02 09:14   48M
site_full.zip           2026-03-02 09:20   212M
wp-config.php.bak       2026-02-11 17:45   3K
error_log               2026-03-10 06:01   9M

In the sample above the SQL dump holds customer rows, the .bak config copy may carry database credentials, and the error log shows server paths and software versions. An attacker can read those versions and pick the next target without a single probe, which is plain reconnaissance.

The weakness is catalogued as CWE-548 weakness entry, Exposure of Information Through Directory Listing, and its listed mitigation is to turn automatic listings off. MITRE maps it to the OWASP Top 10 under Security Misconfiguration in 2013 and 2017 and Broken Access Control in 2021. It is information disclosure, not a ranking factor, but a listing is ordinary linked HTML that crawlers can follow into files you never meant to publish. If an exposed file ever triggers a Google warning, the Safe Browsing check is the next stop.

How SEO Site Checker tests directory browsing

The test is deliberately small. Our report sends one plain GET request to the address you submitted, adds a trailing slash if it is missing, follows redirects and gives up when the server stays silent for 3 seconds. That limit covers connecting and each wait for data, not the whole exchange.

The exact rule: the response text is searched for the phrase Index of /, which Apache and Nginx print in the title and heading of an auto generated listing. If it is there, the item fails. Status codes are not inspected.

What the test does

The request goes to the page you entered, usually your home page. No folder names are guessed.

What pass and fail mean

Only the text matters, so a 403, a 404 and even a 500 all count as a pass. The table shows the five cases.

A pass means the tested address showed no auto generated list. It does not prove /uploads/ or /backup/ are closed, because those were never requested.

What the test cannot see

Other servers word their lists differently. Python's http.server titles its page Directory listing for /, and IIS puts the host name and path in the title (we did not test IIS in the lab), so those pass unnoticed. A 500 from a broken .htaccess also passes, and a page that merely contains the words Index of / would fail by mistake. In our lab we ran the same logic against Apache 2.4.58, Nginx 1.24.0 and Python http.server: the Apache and Nginx lists failed, closed folders returned 403 and passed, and the Python list passed.

Run the free SEO report

How to check if directory browsing is enabled

1. Run the report. Scan your home page and read the line labeled Directory Browsering Check, which is how the report currently spells it.
2. Open a real folder. In a private browser window, visit a folder that has no index file, for example https://example.com/wp-content/uploads/ on WordPress. A page titled Index of /wp-content/uploads means it is open, while a 403, a 404 or a normal page means it is closed.
3. Use curl. From a terminal, request the same folder, follow redirects and search the output for the marker.

curl -sL https://example.com/wp-content/uploads/ | grep -i "Index of"

The -L flag follows redirects like our report does. Without it, a redirecting folder returns an empty body, which looks like a pass. If grep prints a line, the folder is listing. Repeat it for each top level folder, subdomain and download host, since the setting can differ.

How to disable directory browsing on Apache, Nginx and IIS

First learn which server you run: the Hosting Checker shows it. The same config files often hold the leak covered by the Server Signature check, so fix both together.

Apache and .htaccess

Add Options -Indexes to the relevant Directory block in httpd.conf or the virtual host, then reload with apachectl graceful. The directive is documented in the Apache Options directive reference.

<Directory "/var/www/example.com/public">
    Options -Indexes
</Directory>

On shared hosting without server access, put the same line in .htaccess instead.

Two traps showed up in our lab: AllowOverride None silently ignores the .htaccess line, and AllowOverride FileInfo alone makes the site return a 500 error. Mixing options that carry a plus or minus sign with plain ones is invalid syntax and Apache rejects it.

Nginx

The autoindex directive defaults to off, so look for autoindex on in nginx.conf or a site file, in the http, server or location block, and remove it or change it. Check the file with nginx -t, then reload. The behavior is described on the Nginx autoindex module page.

location /downloads/ {
    autoindex off;
}

IIS

Set directoryBrowse to disabled in web.config under system.webServer, or open the Directory Browsing feature in IIS Manager and choose Disable. The default is already false, so a listing means someone enabled it.

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

cPanel, LiteSpeed and WordPress

In cPanel, the Indexes tool (Index Manager in some themes) lets you set a folder to No Indexing. LiteSpeed reads the same .htaccess line as Apache, and on WordPress you should place Options -Indexes in the root .htaccess outside the BEGIN WordPress and END WordPress markers, because core rewrites everything between them.

Success looks like a 403 Forbidden on the folder, which is correct, not a fault.

Directory browsing mistakes that keep the check failing

Most stubborn cases come from an edit that never took effect. Once it is fixed, re-run any scanner that flagged the folder.

Diagnosis shortcut: after an .htaccess edit, a 500 error means AllowOverride does not include Options, while an unchanged listing means AllowOverride is None or you are editing the wrong layer. Either way, move the line into the virtual host config.

• Wrong layer. A proxy, CDN origin or second server may serve the folder with its own settings. Request it on the origin and through the CDN, then compare.
• A hiding attempt. A Disallow rule only asks crawlers to stay away and publishes the folder name, so read the robots.txt guide first.
• A local override. A subfolder with its own .htaccess can set Options +Indexes again,
• Stale results. Skipping the reload, or testing a cached page, makes a correct fix look broken.

Best practices for keeping folder listings closed

• Default to off. Keep indexing disabled server wide and enable it only for a deliberate download folder.
• Clean the web root. Never leave backups, SQL dumps or env files where the server can serve them. Migrations are the usual source, because old backups ride along into the new web root.
• Add layers. A blank index.html is a cheap second barrier.
• Re-test often. Check again after every migration, host change or plugin install.
• Assume exposure. If a backup, dump or env file was ever listed, delete it and rotate passwords and keys. If the site was abused, follow the blacklist cleanup guide.