Directory Listing Enabled
debt(d3/e1/b3/t5)
Closest to 'default linter catches the common case' (d3). The term's detection_hints.tools lists owasp-zap, nikto, and lighthouse — these are standard security scanners that will flag directory listing as part of routine scans. While not compile-time, these tools are commonly used in CI/CD pipelines and catch this misconfiguration automatically.
Closest to 'one-line patch or single-call swap' (e1). The quick_fix explicitly states adding 'Options -Indexes' in .htaccess or 'autoindex off' in nginx config — both are single-line configuration changes that immediately resolve the issue.
Closest to 'localised tax' (b3). This is a server configuration issue that applies only to web contexts per applies_to. Once fixed at the server level, it doesn't impose ongoing maintenance burden. The fix is localized to configuration files and doesn't affect application code or architecture.
Closest to 'notable trap' (t5). The misconception field explicitly states developers believe 'directory listing is harmless if there are no sensitive files present' — this is a documented gotcha. The trap is that it reveals application structure, version numbers, backup files, and admin paths that aid attackers, even when no obviously sensitive files exist. Most developers eventually learn this, but it contradicts the intuition that 'hidden' means 'secure'.
Also Known As
TL;DR
Explanation
When a web server has directory listing enabled and no index file exists in a directory, it returns an HTML listing of all files — including backup files, configuration files, log files, and source code. Attackers use this to map the application's structure and download sensitive assets. Disable directory listing in your web server configuration (Options -Indexes in Apache, autoindex off in Nginx), and ensure all sensitive directories have an index file or are outside the web root.
Common Misconception
Why It Matters
Common Mistakes
- Not adding Options -Indexes to .htaccess or equivalent server configuration.
- Relying on files being 'unlinkable' rather than enforcing access controls at the server level.
- Uploading backup files (.sql, .zip, .bak) to web-accessible directories.
- Testing directory listing protection in development but not verifying it is applied in production.
Code Examples
# Apache config with directory listing enabled:
<Directory /var/www/html/uploads>
Options Indexes FollowSymLinks # WRONG — remove 'Indexes'
AllowOverride None
</Directory># nginx — disable directory listing
server {
autoindex off; # explicitly set — default is off, but be explicit
}
# Apache
Options -Indexes
# Never store sensitive files inside webroot:
# .env, composer.json, .git → keep one directory above public/
# PHP catch-all for requests that reach index.php:
if (is_dir(realpath(__DIR__ . \$_SERVER['REQUEST_URI']))) {
http_response_code(404); exit;
}
# Verify:
$ curl -I https://yourapp.com/storage/
# Should return 403 or 404, never a file listing