What it is
Forgotten files outlive the deploy that created them. Someone wrote a quick `backup.sql` before a risky migration in 2022, dropped it in `/public` because that was the easiest path at 11pm, never came back to clean it up. Two years later it's still there, and the database it dumped is now a different database with different secrets in different schemas — but every one of those secrets is still real. The bug is operational rather than architectural: nobody designed `backup.sql` into the deployment, but nobody removed it either, and the static-file server happily serves anything in its directory. There are public scrapers continuously checking the obvious paths against every domain on the internet, looking for exactly this.
How it happens
Static hosts and web servers serve whatever sits in the public directory. Files that were never meant to ship end up there all the time: an environment file copied into the build output, a git directory deployed along with the code, a database dump saved next to the app before a risky migration, a leftover config backup or editor swap file. None of them is linked from your pages, but they sit at predictable names, and automated scrapers request those names against every domain they can find. The report names each file that is publicly downloadable and what kind of data it holds.
Common variants
Exposed .env
Every secret in plain text. Database URLs, API keys, JWT signing secrets, Stripe keys, OAuth client secrets. Most damaging single file leak.
Exposed .git directory
Full repo history reachable. With dvcs-pillage or git-dumper, attacker reconstructs every commit including ones that briefly contained leaked credentials before being 'removed.'
Backup files
`backup.sql`, `db_dump.sql`, `users.csv`. Direct customer data exposure. Usually one curl command from total compromise.
Editor swap files
Vim's `.swp`, Emacs's `#file#`, Mac's `.DS_Store`. Reveal directory contents, sometimes session state.
What an attacker gets
An exposed environment file is the worst case: every secret your app needs to run, in plain text. An exposed git directory lets anyone rebuild your repository locally, including old commits with credentials that were deleted but never rotated. Backup files are direct customer-data leaks. Editor and OS metadata files are mostly reconnaissance, but they can reveal paths that should stay private. Each finding is potentially the breach.
// what fixvibe reports
What FixVibe reports
Runs on every URL scan: paste your app's URL, nothing to install. The free preview shows your top findings; Hobby and above unlock the full report. Each finding shows the affected URL or host, its severity and fix steps you can paste into your AI coding tool.
How to fix it
Keep dotfiles and backups out of anything you deploy. Add a CI step that fails the build when the output directory contains dotfiles, SQL dumps, or backup files, and audit the build output of static-site frameworks after deploy. Configure your web server or CDN to refuse requests for dotfiles, and prefer a 404 over a 403 so you do not confirm that a file exists. Never commit environment files to git; if one slipped in, rotate every secret it held and remove it from history with a tool such as git filter-repo. Add environment files, dumps, backups, and editor swap files to `.gitignore` when you start the project.