What it is
Behind every store sit files that were never meant for visitors: configuration files holding database passwords, a .env with API keys, a .git folder with your source code, log and cache folders, and leftover database backups. On a correctly configured server, asking for any of these returns an error. When the server hands one back instead, anyone who guesses the address can read it.
How common it is
Just over half of audited stores (57%) keep these files locked away. The audit requests the usual culprits directly, the config file, .env, .git, log and cache folders, composer files, and common backup names, and passes only when the server refuses every one. A single readable file fails the check, because one is enough.
Why it costs you
This is one of the shortest paths an attacker has, and it needs no break-in. A reachable .env or config file usually holds the database credentials, which means the customer table, the order history, and saved addresses in a single download. An open .git folder hands over your source, where an attacker reads your exact version and payment setup and looks up known holes to walk through. A forgotten store.sql backup in the web root is the whole database sitting in public, found by scripts that scan thousands of sites a day for that one file. None of it shows on the storefront, so the first sign is often the breach itself.
Check it in 30 seconds
On your own site, try opening yourstore.com/.env and yourstore.com/.git/ in a browser. A 403 or 404 is what you want. If either returns text, a file, or a folder listing, it is readable by anyone and needs blocking today.
Read next: Ecommerce Security: The Losses You Don’t See
Run the free audit to see whether any private file on your server answers to the public.