Vulnerabilities
Directory Listing vs 403 for Backup and Static Folders
June 4, 2023
Directory listing vs 403 for backup and static folders is a map-versus-lock decision. Autoindex (an 'Index of /' HTML page) lists every file the web server will serve in that path — backups, old zips, leftover SQL dumps, copy-of-config. A 403 or a generic 404 without a listing does not advertise the names. It still does not make a guessed /backup.zip safe: if the file exists and returns a zip signature, that is an exposure. RoastMyOpsec uses bounded GETs to well-known backup and VCS paths and checks content signatures. It does not crawl directory trees or brute-force filenames.
The practical difference
A listing is an inventory gift. Anyone who finds /files/ or /backup/ sees the names you thought were obscure. A 403 is an honest deny. A 404 is an honest miss — unless it is a soft-404 SPA shell, which is a different lie (see the soft-404 guide).
Turning off autoindex is necessary and not sufficient. Files you uploaded 'just for a minute' remain downloadable at the exact URL. Block backup extensions and VCS prefixes at the CDN as well.
How to choose what to configure
Static marketing assets can live in hashed filenames under /assets with listing off. Anything named backup, dump, old, copy, or .zip/.sql/.tar does not belong on the public origin. Put archives in object storage that is not the website, with no public ACL.
If you must keep a private drop folder, it is not a website path. Use signed URLs or a VPN. robots.txt Disallow is not a lock.
| Response | What a stranger learns | What is still true | Takeaway |
|---|---|---|---|
| Index of /backup | Every filename in the folder | Each file may still download | Disable autoindex; remove the files |
| 403 on /backup/ | The path exists and is denied | Exact file URLs may still 200 | Deny the prefix at the edge |
| 404 generic on /backup.zip | Little | Good if the object is gone | Confirm the body is not a zip |
| 200 with PK zip magic | The archive is public | Listing was optional | Incident: rotate, delete, deny |
What the roast actually checks
The free path plan looks for common sensitive paths — including backup-shaped names — and usable file signatures (for example a zip magic number). It will not enumerate every object in a bucket. A clean roast is not a guarantee nobody left archive.tar.gz under a unique name.
Pair with exposed .git/.env and soft-404 so a 200 homepage on /backup.zip is not mistaken for a miss.
Common mistakes
The first mistake is turning off listing and leaving last-week.zip in the same folder.
The second mistake is Disallow: /backup in robots.txt as if crawlers were the threat.
The third mistake is serving user uploads from a world-listable prefix next to the marketing site.
Free audit the URL you own
RoastMyOpsec is a defensive public-surface roast: headers, cookies, sensitive paths, and more — no exploit payloads. Start with the free audit, then open the vault if the blurred findings look expensive.
Free audit nowFAQ
- Is directory listing a vulnerability?
- It is an information leak that often becomes a dump. Treat it as a finding. Remove listings and the sensitive files.
- If listing is off, are backups safe?
- No. Guessable names still download. Keep archives off the public origin and deny backup extensions at the CDN.
- Does RoastMyOpsec spider every folder?
- No. Bounded GETs to well-known paths plus signatures. No recursive listing, no filename brute force.
Sources
Related guides
Vulnerabilities
.htaccess vs web.config on a Public OriginVulnerabilities
.DS_Store vs Directory Listing for Leftovers on ProductionVulnerabilities
Exposed .git vs .env on Production Websites