A downloadable keystore.jks or site-backup.zip is your whole app in one file

Some exposed files leak a setting. These two leak everything at once. A Java keystore is the container your app keeps its private keys in, TLS keys, signing keys, the credentials that prove your services are who they say they are. A backup archive is the whole site folded into a single download: source code, config, and whatever secrets were sitting on disk when someone ran the backup. Either one, downloadable, is a catastrophe in a single GET.

What's interesting about both is how they're caught. You can't reliably find them by filename, an attacker renames a backup, a keystore has a dozen conventional names. The scanner finds them by their magic bytes: the fixed signature in the first few bytes of the file that says what it really is, regardless of what it's called. That's a more honest test than the name, and it's why these get their own family.

The keystore: a vault with the keys still in it

Java apps store their cryptographic keys in keystore files, JKS (the classic Java KeyStore) or JCEKS (its encrypted cousin). Inside are the private keys and certificates the app uses: the TLS key that secures its connections, signing keys, sometimes client certs for talking to other services. The keystore is password-protected, but keystore passwords are routinely weak, hardcoded in config, or set to defaults like changeit (the literal Java default that ships in tutorials and never gets changed).

So a downloadable keystore is two problems. First, it confirms exactly which keys exist and which services they protect. Second, it's an offline target: an attacker downloads it and brute-forces the password at their leisure, with no rate limit, no lockout, no log on your side, because the cracking happens on their machine. Crack it and they hold your private keys, which means impersonating your services and decrypting traffic the keys protect. The scanner identifies a keystore by its magic bytes, FE ED FE ED for JKS, CE CE CE CE for JCEKS, at the start of the file, so a renamed keystore, .keystore, server.jks, or app.jks is caught for what it is, not what it's called.

The backup archive: the entire app, zipped

The other file is the one a developer made on purpose and forgot to delete. Before a risky change, before a migration, "just in case", someone ran a backup and dropped the result in the web root: backup.zip, www.tar.gz, <sitename>.zip. It's the whole application directory in one file, and the whole directory is exactly what you don't want public: the source code (so an attacker reads your logic and finds bugs offline), the config files (so they get the .env, the connection strings, the API keys), and any data that happened to be in the folder.

A backup archive is strictly worse than any single exposed file, because it's all of them at once, plus the source. It's the leftover database dump problem generalized to the entire app. The scanner catches it by archive magic bytes, zip's PK\x03\x04, gzip's 1F 8B, plus 7z/rar/xz/bzip2, on a canonical or host-named backup path, so a renamed archive is still recognized as an archive.

The fix: don't keep these where a web server can serve them

Neither of these belongs in a directory the web server can reach, ever. Keystores live with the app process that uses them, outside the document root, readable only by that process. Backups go to object storage with public access blocked, or somewhere off the web host entirely, never into a folder the site serves.

/var/www/html/
keystore.jks          <-- private keys, served
www-backup.zip        <-- entire app + .env, served
index.html

And if either was reachable for any length of time, treat the contents as compromised: rotate the keys in the keystore (reissue and revoke), and rotate every credential that was inside the backup. A deleted file that was already downloaded is still leaked.

Reading it from outside

Whether your keystore or a stray backup answers an anonymous request is something a stranger settles by fetching the path and checking the first few bytes, which is exactly what SurfaceCheckr does. It requests the canonical and host-derived names, reads only the leading bytes of the response, and confirms a hit by the magic-byte signature, a real JKS/JCEKS keystore, a real archive, never just a 200 or a matching filename. It doesn't pull the whole file down; it confirms the file is what it claims to be and stops. That magic-byte gate is what makes the check honest: an attacker who renames their loot doesn't fool it, and a soft-404 that 200s everything doesn't trip it. It's the difference between "a file with this name exists" and "your vault is downloadable right now."