Can strangers browse your folders?

Visit a folder on your site that has no index resource — say /uploads/ or /backups/ — and if automatic indexing is enabled, the server may return a listing of what's inside. And it may do the same for anyone else, including attackers and scrapers. Directory browsing (autoindex) doesn't grant access to anything — but it makes files that are already reachable over HTTP much easier to discover. Turn it off, and treat it as only one layer.

Why this is a real risk

• Information disclosure. A listing can reveal filenames, subdirectories, sizes and dates — useful reconnaissance for that part of the site.
• Accidental data leaks. A db-backup.sql, clients.xlsx, or .env.example dropped in a public folder is trivially found through a listing — and still downloadable by direct URL without one.
• Automated harvesting. Scanners discover open listings and fetch whatever's linked from them.

Takeaway: Switch off directory listing, deny what must stay private at every layer that answers requests, and above all keep secrets out of the web root — a hidden listing is not a locked door.

What to do

1. Disable autoindex. On Apache — in .htaccess where the host permits the Options override, otherwise in the server configuration:

   Options -Indexes

   On Nginx, autoindex off; is the default — confirm it in the location actually serving the path, since scopes inherit and override each other.

2. An index file is a backup measure only. An index.html the server recognizes suppresses the listing for that directory request — it protects nothing that's requested by name.
3. Keep sensitive files out of the web root entirely. Backups, credentials, and data exports belong above the document root or in storage that isn't served over HTTP. This is the strongest control on this page — everything else is damage limitation.
4. Deny dotfiles and backup suffixes — knowing the list must match your site's actual suffixes (this one is case-sensitive and covers only what it names), and that removal beats maintaining a denylist:

   <FilesMatch "(^\.|\.(bak|sql|log|env)$)">
     Require all denied
   </FilesMatch>

   FilesMatch matches filenames only, not folders — the files inside a .git directory (like .git/config) have ordinary names and slip straight through. Block the directory itself, with a pattern that won't also catch .github or .gitignore:

   RedirectMatch 404 "(?i)(?:^|/)\.git(?:/|$)"

5. Protect private areas with real authentication — on Apache, Basic auth via .htaccess with the password file stored outside the document root, over HTTPS only, and never with credentials embedded in a URL. (This needs the host to permit AuthConfig overrides.)
6. Verify at the public URL, both ways. Request a test directory with no index resource and confirm no generated listing appears — a 403, a 404, and a custom page are all acceptable outcomes. Then request a harmless known file directly to confirm your deny rules bind. Test through the front door: an Apache rule protects only requests that reach Apache, so if a proxy, CDN or separate static-file layer can answer first, configure and test that layer too — and purge any previously cached listing.
7. Delete leftover backups — don't just hide them. On a correctly configured PHP site, config.php is executed rather than served; a copy named config.php.bak or config.old may be served as plain static text, depending on configuration — and if the PHP handler ever fails, even the live file can leak. Remove obsolete backups from the document root, move non-public include files outside it where the application allows, and where it doesn't, deny direct access and test the denial before trusting it.