criticalSeverity: criticalRisk ratingHow usable this gap is to an attacker. Severity sets the posture penalty: critical −40, high −20, medium −10, low −4, info −1. Higher severity means fix it sooner.Deploy config / web serverWhere it livesImplementationThis fix is applied in: Deploy config / web server. That's the surface you'll edit, DNS, response headers, or a static file.~15 minTime to fixEffortRoughly 15 minutes of hands-on work, propagation aside. Most of these are copy-paste.+40 posture+40 postureScore impactPoints this fix recovers in the ApeCyber posture score (0–100). Posture = 100 minus the severity penalty of every open finding; clearing this finding adds these points back.

Exposed database dump: pull the .sql file and treat the data as out

Removing a public .sql dump and moving backups off the web server stops anyone from downloading a full copy of your database

The threat

The scanner requested a path like /backup.sql (or dump.sql, database.sql) and got back SQL: CREATE TABLE, INSERT INTO, real rows. A dump is a complete, portable copy of your database, every table and every row it held when it was exported: customers, emails, addresses, order history, whatever your app stores. Sitting under the web root, it downloads like any other file.

There are two kinds of harm here. The obvious one is the data itself, now copyable in bulk. The quieter one: dumps often carry the schema plus GRANT or CREATE USER statements, and sometimes an app connection string, so database credentials can ride along inside the same file.

The exact fix

Step 1, contain.

  • Remove the dump from the web root immediately.
  • Treat the data as exposed. You cannot un-download a file, so assume someone has it and follow your breach and notification policy. In many regions, notifying affected people is a legal obligation, so check what applies to you.
  • Rotate any database credentials that appear in the dump, or that are reused elsewhere. If the file referenced a DB user and password, change them.

Step 2, stop serving backups at all. A database backup should never live where a web server can hand it out.

  • Move backups off the web root, ideally off the web server entirely: a private bucket (S3 or GCS) with no public access, or a separate backup host.
  • Keep dumps out of deploys: add patterns like *.sql, *.dump, *.sql.gz to .gitignore.
  • Block the extensions at the server as a backstop.

nginx:

location ~* \.(sql|dump|sql\.gz)$ {
    deny all;
    return 404;
}

Apache:

<FilesMatch "\.(sql|dump|sql\.gz)$">
    Require all denied
</FilesMatch>

This usually starts as a habit. Running mysqldump > backup.sql inside the site folder and forgetting it is the classic cause. Point backups at a directory outside the served path, and it cannot recur.

Verify it

curl -sI https://yourdomain.com/backup.sql

Swap in the exact filename your report flagged. You want a 404 or 403. A 200 with a Content-Type of application/sql, or a large Content-Length, means it is still downloadable.

Proof

The ApeCyber scanner flags this passively on every scan, from the outside, with a single GET, touching nothing. There is no dump in apecyber.com’s served output because its backups never sit in the web root. At −40 this is the maximum single-finding weight, and it clears as soon as the file is gone and backups live somewhere private.