Is a public SQL dump a vulnerability?

Yes — it is a data exposure. Remove it, deny the path, and rotate anything that may have been inside.

If backup.zip is empty of secrets, is it still a finding?

A public archive on the origin is still an OPSEC miss. Do not host backups next to the marketing site.

Does RoastMyOpsec download and unzip backup.zip?

No. Bounded GET plus magic-byte check. No recursive dump, no exploit payload.

Vulnerabilities

Exposed dump.sql vs backup.zip on Production

August 3, 2023

Exposed dump.sql vs backup.zip on production is the same class of miss in two costumes. A reachable SQL dump is often CREATE/INSERT text — schema and data that never belonged on the CDN. A reachable zip with PK magic is an archive that may hold the dump, the CMS, or .env. Neither is 'just a leftover.' RoastMyOpsec uses bounded GETs to well-known names and checks content signatures (SQL keywords, zip magic). It does not brute-force filenames, unzip archives, or run queries against your database.

The practical difference

dump.sql is usually a mysqldump- or pg_dump-shaped file someone saved 'for a minute.' backup.zip is a folder they compressed. The zip can hide the sql. The sql can hide passwords in INSERT rows. Treat both as credential-adjacent until proven otherwise — then rotate if they were public.

A 200 with a homepage HTML body is a soft-404, not a dump. Grade the signature, then deny the path anyway so the next upload cannot land.

How to choose what to do first

If either path hits: take the object off the origin, deny .sql/.zip/.tar backup names at the CDN, rotate database and app secrets that might have been in the file, and stop copying backups into the web root. Put archives in private object storage with no public ACL.

Object	Signature the roast uses	Usual blast radius	Takeaway
/dump.sql	SQL-ish keywords in the body	Schema and row data	Delete; rotate DB creds if it was live data
/backup.zip	Zip magic bytes	Whatever was zipped	Delete; assume .env until you know
Index of /backup	HTML listing	Names of the above	See directory listing guide
Soft 404 on those paths	Marketing HTML	Confusing, not a dump	Still deny the prefix at the edge

What the scanner will not do

No unzip, no SQL parse beyond a coarse signature, no guessing dump-2024-final-v3.sql. A clean check is not a guarantee a uniquely named archive is absent. CI should fail if backup extensions appear in the publish artifact.

Common mistakes

The first mistake is 'the zip is encrypted' sitting on a public URL anyway.

The second mistake is dumping to /tmp on the web host and letting the docroot include it.

The third mistake is robots.txt Disallow for /dump.sql as if crawlers were the only readers.

Free audit the URL you own

RoastMyOpsec is a defensive public-surface roast: headers, cookies, sensitive paths, and more — no exploit payloads. Start with the free audit, then open the vault if the blurred findings look expensive.

Free audit now

FAQ

Is a public SQL dump a vulnerability?: Yes — it is a data exposure. Remove it, deny the path, and rotate anything that may have been inside.
If backup.zip is empty of secrets, is it still a finding?: A public archive on the origin is still an OPSEC miss. Do not host backups next to the marketing site.
Does RoastMyOpsec download and unzip backup.zip?: No. Bounded GET plus magic-byte check. No recursive dump, no exploit payload.

Sources

Related guides

Vulnerabilities
sitemap.xml vs robots.txt for Hidden Paths
Vulnerabilities
Exposed .git vs .env on Production Websites
Vulnerabilities
.DS_Store vs Directory Listing for Leftovers on Production