The hook
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 works
FixVibe probes a curated list of ~35 high-signal paths against the public web root. The list mixes a few categories: dotfile leaks (`.env`, `.env.local`, `.env.production`, `.git/config`, `.git/HEAD`, `.svn/entries`, `.DS_Store`), backup artifacts (`backup.sql`, `dump.sql`, `db.sql.gz`, `database.bak`), editor temporary files (`.swp`, `~` suffix variants), config files (`config.php.bak`, `web.config.old`, `wp-config.php.bak`), and CI/CD artifacts (`.docker/config.json`, `.npmrc`, `composer.lock` in unexpected places). Each path gets a GET request; we examine response status, content-type, length, and a content-shape signature. A 200 with text matching the expected format is a finding. A 403 or 401 might mean WAF noise, so we also check against a 'baseline' fake-suspicious path to rule out blanket-403 WAFs.
The 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.
The blast radius
Exposed `.env` is the worst case — every secret your app needs to run, in plain text, indexed by Shodan within hours. `.git/config` plus a tool like dvcs-pillage rebuilds your repo locally; old commits often contain credentials that were 'removed' but not rotated. Backup files are direct customer-data leaks. `.DS_Store` is mostly recon (file listing) but occasionally exposes paths that should be private. Each finding is potentially the breach.
// what fixvibe checks
What FixVibe checks
FixVibe maps externally visible application surfaces with passive signals and safe metadata checks. Reports summarize the exposed surface and remediation priorities. For check-specific questions about exact detection heuristics, active payload details, or source-code rule patterns, contact support@fixvibe.app.
Ironclad defenses
Don't deploy dotfiles or backup files to public directories. Your CI pipeline should refuse to ship them — add a build step that fails when `find ./public -name '.*'` or `find ./public -name '*.sql'` returns matches. Configure your web server to block dotfile access at the edge: nginx `location ~ /\. { deny all; }`, Apache `<FilesMatch '^\.'>`, Vercel's `excludeFiles` config. For static-site frameworks, audit the build output directory after deploy. Don't commit `.env` files to git; if one slipped in, rotate every secret and remove via `git filter-repo`. Add a `.gitignore` rule for `*.sql`, `*.bak`, `*.swp`, `.DS_Store` from project init. As a final layer, configure your CDN or web server to return 404 (not 403) for these paths — denying existence is preferable to confirming it.