Verifiedapp Blog
Exposed Files

Exposed SQL dumps: your database, downloadable

· 3 min read
#backups#data-breach#exposed-files#sql-dump

The whole database in one file

A SQL dump is exactly what it sounds like: a single file that contains a complete export of your database. Schema, every row, every user record, every password hash, every email address — all of it, in plain text, ready to be re-imported. That is genuinely useful for backups and migrations. It is also catastrophic if the file ends up somewhere the public web can reach.

There is no clever attack involved here. If the file is downloadable, the attacker just downloads it.

How dumps end up public

It is almost always carelessness with file placement, not a breach:

  • Backups saved into the web root. Someone runs an export and drops backup.sql into the site's public folder for convenience, then forgets it.
  • Predictable filenames. Bots constantly probe for common names — dump.sql, db.sql, backup.sql, database.sql, site.sql.gz — at the site root. They do not need to find a link; they just try the names.
  • Dated archives. A backup-2026-01.sql.gz left from a one-off migration, long since forgotten but still served.
  • Version-control leftovers. A dump committed to the repo, then deployed along with everything else into a public directory.

Because the filenames are so guessable, an exposed dump is usually found by automated scanning quickly — often before any human ever links to it.

Why this is among the worst exposures

Most findings are about risk — a missing header makes an attack easier. An exposed dump is not a risk of a breach; it is the breach. Whoever downloads it has:

  • Every user's email and personal data — a direct GDPR incident.
  • Password hashes to attack offline at their leisure.
  • Your full schema, which maps out the rest of your system.
  • Often, secrets or tokens stored in data rows.

There is no 'they might be able to' here. They already have it.

How to keep dumps private

  • Never write a dump into a web-served directory. Backups belong outside the web root entirely, or in dedicated backup storage that is not internet-facing.
  • Use a real backup destination. Push dumps to private object storage or a backup service, not the application server's public folder.
  • Block the file types at the server. Configure the web server to refuse requests for .sql, .sql.gz, .dump and similar, as a safety net.
  • Clean up after migrations. One-off exports from a migration or debugging session must be deleted, not left to rot in a folder.
  • If one was ever exposed, treat it as breached. Rotate credentials, force password resets, and follow your disclosure obligations.

Check for exposed files

The trouble with a forgotten dump is that nothing on your site links to it — you will not stumble across it, but a scanner will. An automated scan probes for common backup and dump filenames the way a bot would and reports any that respond. Scan your site and find out if your database is sitting in the open.

Related reading

FAQ

How would a SQL dump even get found if nothing links to it?
Bots do not need a link. They request common backup names like backup.sql, dump.sql or db.sql.gz directly at the site root. Because these filenames are so predictable, an exposed dump is usually discovered by automated scanning, not by following a link.
What is actually in a SQL dump?
A complete copy of your database: schema plus every row. That typically means all user emails and personal data, password hashes, your full table structure, and sometimes secrets stored in data. An exposed dump is effectively a finished data breach.
Where should database backups go instead?
Outside the web root entirely — private object storage or a dedicated backup service that is not internet-facing. Never write a dump into a folder the web server serves, and configure the server to refuse requests for .sql and similar files as a safety net.

Keep reading