← Back to the Backup File Exposure Checker
Typing yoursite.com/backup.zip into a browser tab is a real, fast way to spot the
single obvious case: the browser either offers to download a file or shows a 404. It is also the
method most developers already reach for first, and it genuinely works for that case.
| Check | Typing the URL by hand | This tool |
|---|---|---|
| Obvious downloadable archive or dump | Catches it | Catches it |
| A server that returns 200 with a generic page for any path (soft-404) | Can look plausible enough to misread either way | Verified against a real archive's magic bytes or a real SQL dump's line shape before calling anything exposed |
| Checking all eight common backup filenames, not just one | Manual, easy to stop after trying the one you thought of | Checks backup.zip, backup.tar.gz, backup.sql, backup.sql.gz, db.sql, database.sql, dump.sql, and site.zip every run |
| Confirming a match without reading row data by hand | Opening the file to check risks reading real row content | Confirms from the header/structural shape alone; row-data statements are counted, never quoted |
| Repeatable in CI on every deploy | Manual, point-in-time | CLI returns a real exit code |
If you only need a one-off sanity check on a URL you're already typing into the address bar, looking is fine — it's free and you're already there. The gap this tool closes is coverage and confidence: all eight relevant filenames, not just the one you thought to try, each verified against real structural evidence rather than eyeballed, every time a deploy happens, with an exit code a CI pipeline can act on.
Typing yoursite.com/backup.zip into a browser tab is a fast, real check for the single obvious case: the browser either offers to download a file or shows a 404. If it downloads, you don't need a tool to tell you it's exposed -- though you may not notice whether the downloaded file is actually a real archive or just some other binary-looking response until you open it.
Three ways this scripted check catches and a quick manual look easily misses: (1) a server that returns its normal 200 page (a single-page app's fallback route, a themed 404) for literally any path -- a download prompt or a page that loads without obviously erroring can be misread either way without checking the actual bytes. (2) Checking only the one filename you thought to try, not the seven other common ones (backup.tar.gz, backup.sql, backup.sql.gz, db.sql, database.sql, dump.sql, site.zip) a backup script or a careless one-off save could have used. (3) Opening a downloaded file to confirm it's real, and to see what's inside, risks reading actual row data by hand -- this tool confirms a match from the file's header or structural shape alone and deliberately never shows row-data content.
A manual check is a point-in-time look. A new backup script, a forgotten one-off save, or a server configuration change can reintroduce this exposure at any point after the last time someone happened to check. The CLI here returns a real exit code, so it can gate a deploy the same way a linter or test suite does -- catching a regression the day it ships rather than the next time someone thinks to check by hand.