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.~10 minTime to fixEffortRoughly 10 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 backup archive: delete the .zip and move backups off the web

Deleting a public site archive and rotating any secrets inside it stops attackers from downloading your whole site in one file

The threat

The scanner found a downloadable archive under your web root, something like /backup.zip, /site.tar.gz, /www.zip, or /backup-2026.zip. These are usually made by a “download a full backup” button in a hosting panel, or a hand-run tar or zip of the site folder. Whatever the origin, the archive is a single file that holds the whole site.

“Whole site” means more than pages. It is the application source, the server config, and very often a bundled .env or config file with live secrets, plus a database dump if the backup was full. One download hands over all of it at once, and backup-hunting bots look for exactly these filenames.

The exact fix

Step 1, contain: rotate any secret the archive contained. Assume it was downloaded, then treat everything inside as public:

  • Rotate database passwords, API keys, tokens, and mail credentials that were in the bundled config or .env.
  • If the archive included a database dump, treat that data as exposed too, and follow the steps on the database-dump page.

Step 2, stop serving backups. A backup is only safe where a web server cannot reach it.

  • Delete the archive from the web root now.
  • Store backups off the web server: a private bucket or a separate host, never a folder the site serves.
  • Keep archives out of deploys: add *.zip, *.tar, *.tar.gz, *.bak to .gitignore.
  • Block the extensions at the server as a backstop.

nginx:

location ~* \.(zip|tar|tar\.gz|tgz|bak|old)$ {
    deny all;
    return 404;
}

Apache:

<FilesMatch "\.(zip|tar|tar\.gz|tgz|bak|old)$">
    Require all denied
</FilesMatch>

The backup and the website should never share a directory. If your host defaults to keeping backups in public_html, change it. A backup living beside the pages it protects is a backup one URL guess away from the public.

Verify it

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

Use the exact filename from your report. A 404 or 403 is what you want. A 200 with a large Content-Length means the archive is still there for the taking.

Proof

The ApeCyber scanner flags this passively, from the outside, with a single GET, touching nothing. apecyber.com’s backups and build inputs never sit in the served output, so there is no archive to fetch. At −40 this is one of the heaviest posture hits, and it clears the moment the file is gone and backups live somewhere private.