Backup File Exposure Checker

Paste your site's URL. This sends a plain GET request to eight well-known backup filenames (backup.zip, backup.tar.gz, backup.sql, backup.sql.gz, db.sql, database.sql, dump.sql, site.zip) and verifies each response against a real archive's magic bytes or a real SQL dump's line shape — not just an HTTP status — before calling anything exposed. It never extracts a matched archive's contents, and it never quotes a SQL dump's row-data statements — only schema statements (table/column structure) are ever shown. See why backup files end up in web roots for the common causes and the fix for each. Only run this against a site you own or are authorised to test.

Run the check

Enter a site URL, then click Check.

Prefer a CLI, or hit a CORS wall in the browser?

Most servers don't send permissive CORS headers on arbitrary static paths, so a browser tab often cannot read a cross-origin response at all — you'll see a generic network error with no HTTP status. The CLI has no such restriction and is the one path guaranteed to complete: 

node check.mjs https://example.com/ --json

Get check.mjs, probe.mjs, and analyze.mjs from the repo — exit code 1 if any path is exposed, so you can gate a deploy on it.

Common questions

Why would a production site have a backup file sitting in its web root?

Usually a one-off manual backup ("let me zip the site before I deploy this change") saved directly into the web-served directory instead of somewhere off the deploy path, or an automated backup cron job that writes its output into the same document root the web server serves as static files. Either way the file sits right next to the site it is a copy of, servable like any other file until something removes it or blocks it.

Does this tool download or read the actual contents of my backup or database dump?

No. Each request reads at most 8KB of the response — enough to confirm a real archive's magic-byte header or a real SQL dump's opening lines, never enough to be "downloading the backup". For an archive, only that header is ever shown as evidence — this tool never lists, extracts, or reads a file from inside it. For a SQL dump, only schema statements (CREATE/DROP/ALTER TABLE — table and column structure) are ever quoted; row-data statements (INSERT, REPLACE, COPY ... FROM stdin) are counted but their text is never shown, because that is where real row content — potentially real customer data — would be.

How is this different from just typing the URL into my browser?

A browser tab shows you the raw response, but many servers return their normal 200 page (a single-page app's fallback route, a themed 404) for literally any path — which can look plausible enough to misread as an exposure, or a real one might download as an unreadable binary blob you can't quickly confirm. This tool verifies the bytes actually match a real archive's magic-byte header or a real SQL dump's line shape before calling anything exposed, and checks eight well-known filenames in one run instead of one at a time. See how this compares to checking by hand.

Is it safe to point this at a URL?

This tool sends only ordinary GET requests to the eight paths under the URL you name — the same requests your own browser already makes when you type one of those URLs in by hand — and it never writes or submits anything. It does not upload the URL or anything it finds to our servers when run in the browser; every request goes straight from your browser to the target. Still, only run this against a site you own or are authorised to test, the same caution you'd apply to any request tool aimed at someone else's server.

Does a clean report mean my deployment has no backups exposed anywhere?

It means the eight paths this run checked either returned a clean 401/403/404 or did not match a known archive or SQL dump shape. It does not check other common exposure paths (a stray .git directory, a .env file, a differently-named backup), does not crawl the rest of the site, and only checks the one base URL you give it. Treat a clean report as evidence about what this run actually found, not a full audit of the deployment.