Vulnerabilities
.DS_Store vs Directory Listing for Leftovers on Production
July 25, 2023
.DS_Store vs directory listing is two ways a static folder donates names. A public /.DS_Store (or one under /assets) is Apple Finder metadata that can include filenames from the folder someone synced. An 'Index of /' page is the same idea with HTML. Listing is louder; .DS_Store is the leftover that survives after autoindex is turned off. Neither is access control. RoastMyOpsec probes /.DS_Store with a bounded GET and looks for a known binary signature. It does not parse the file into a treasure map and it does not crawl every subdirectory.
The practical difference
Directory listing is a web-server feature. .DS_Store is a desktop OS feature that hitchhiked into the deploy tarball. Marketing teams that zip a Mac folder onto S3 ship both unless the pipeline strips dotfiles.
A hit on /.DS_Store is an information leak. It is not proof a backup.zip exists — but it is a reason to deny dotfiles at the CDN and add them to the 'do not publish' list next to .env and .git.
How to choose what to fix
Strip .DS_Store, Thumbs.db, and .git in the CI publish step. Deny those names at the edge even if CI is perfect. Turn off autoindex. Then look for backup.zip and dump.sql the same week — they are the payload, the metadata was the map.
| Leftover | What it often reveals | Typical cause | Takeaway |
|---|---|---|---|
| /.DS_Store | Filenames from a Mac folder | Drag-drop deploy, unsanitized zip | Strip in CI; deny at CDN |
| Index of /static | Every object in the prefix | Autoindex left on | See directory listing vs 403 |
| /backup.zip | The archive itself | Temporary upload that stayed | Incident if the signature matches |
| /package.json | Dependency inventory | Repo root copied to dist | See public package.json guide |
What the roast will not do
No recursive walk of every prefix looking for nested .DS_Store. No guide to decoding Finder records. A short or empty body is not counted as a hit. Soft-404 HTML is not a signature match.
Common mistakes
The first mistake is deleting the file once and not denying the path, so the next intern zip brings it back.
The second mistake is gitignoring .DS_Store locally and still uploading a zip that contains it.
The third mistake is treating a .DS_Store finding as equal to an exposed .env.
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 .DS_Store a vulnerability?
- It is an information leak. Remove it and deny the name. It is not the same as a credential dump.
- If listing is off, can .DS_Store still leak names?
- Yes. The file is a separate object. Turning off autoindex does not delete Finder metadata you uploaded.
- How does RoastMyOpsec detect .DS_Store?
- A bounded GET and a binary signature check. No recursive dump, no exploit payload.
Sources
Related guides
Vulnerabilities
Thumbs.db vs .DS_Store on Production CDNsVulnerabilities
.vscode vs .DS_Store on Production OriginsVulnerabilities
desktop.ini vs Thumbs.db on Production CDNs