The fix, in one snippet
find . -name '.DS_Store' -delete
echo '.DS_Store' >> .gitignoreIllustrative values. Change the paths, hostnames and options to match your own site before using it.
The sections below explain what is tested, why it matters and the alternatives.
What we test
Scan.now requests /.DS_Store and, if the directory-listing probes touched other directories, /.DS_Store inside a few of those. A finding requires an HTTP 200 whose first eight bytes are the Finder metadata signature 00 00 00 01 42 75 64 31 ("Bud1"); an HTML error page with a 200 status does not count. Only the first bytes are read, and the file is not parsed for names. Rated low: the file discloses names, not contents, but a name is often enough (backup-2024.zip, admin-old/). Its presence also indicates that the site was deployed by copying a folder from a Mac, which makes other stray artefacts likely; see exposed-git-directory and exposed-backup-files.
Why it matters
Finder writes a .DS_Store into every folder it displays to remember icon positions and view settings, and the file includes the name of every entry in the folder. Uploaded to a web server, it becomes a directory listing that works even where autoindex is off. Public tools parse it and recursively fetch the .DS_Store of each subfolder it names, mapping the whole tree. The practical harm is discovering unlinked files: a backup archive, an old copy of the site, a spreadsheet dropped in the root "temporarily", or an admin area that relied on nobody knowing the path. Because the file is small and easy to overlook, it tends to survive for years. The exposed files guide explains how scanners chain these small leaks together.
How to fix it
Delete every copy on the server and stop new ones from arriving:
find /var/www -name .DS_Store -deleteExclude it from deployments. rsync:
rsync -av --exclude='.DS_Store' --exclude='.git' ./site/ user@host:/var/www/site/Add .DS_Store to .gitignore (and to a global gitignore on every Mac in the team). Stop Finder writing them on network and USB volumes:
defaults write com.apple.desktopservices DSDontWriteNetworkStores -bool true
defaults write com.apple.desktopservices DSDontWriteUSBStores -bool trueFinally, block all dotfiles at the web server, which also covers .git, .env and editor swap files. nginx: location ~ /\.(?!well-known/) { deny all; return 404; }. Apache 2.4: <FilesMatch "^\.">Require all denied</FilesMatch>. Cloudflare WAF: block paths containing /.DS_Store.
Where this fits
Exposed .DS_Store file is check 9 of 14 that the website vulnerability scanner runs under exposed files and information disclosure, ordered the way they are worth fixing. That ordering is the point: Fixing this one while the check above it still fails buys less than it looks like.
Fix this one first
Above it in the same category sits WordPress xmlrpc.php enabled (medium), where the WordPress XML-RPC endpoint at /xmlrpc.php is enabled. An attacker who has that does not need this, so it is the better use of the same hour.
What fixing this still leaves open
Exposed .DS_Store file closes one route in. Immediately below it: HTTP TRACE method enabled, where the server answers HTTP TRACE requests by echoing them back; WordPress version disclosure, where the site runs WordPress and reveals its exact core version through the generator tag, asset query strings, readme.html or the feed, letting attackers match it against known core vulnerabilities; Redirect parameters on the page, where links or forms on the page carry parameters whose names and values suggest a redirect target (next=, return_to=, url=).
Found in the same scan
The website vulnerability scanner reports this alongside checks from other categories that are at least as serious, including Certificate chain and hostname validation, where the certificate presented for this hostname did not validate: The chain does not reach a trusted root, an intermediate is missing, the name does not match, or the certificate is self-signed or expired, and HTTPS is available, where the site could not be reached over HTTPS on port 443, or the TLS handshake failed. A single run of website vulnerability scanner answers all of them at once.
The first few lines
You are a senior web engineer. I ran a security and SEO scanner against my site and it reported the finding below. Fix it properly rather than suppressing the symptom.
Finding: Exposed .DS_Store file (low severity)
Scanner check id: exposed-ds-storeThe rest of this prompt names the pages and line numbers we found the problem on, the configuration to change, and the constraints a good answer has to respect. It is free, it just needs an account so the work is not scraped wholesale.
Sign in with GoogleSigning in is free and takes one click. We store your email address and nothing else.
