Scrubbing secrets from a backup before you store it

23 October 2026Majed Alandajani

Automated backups are the right idea. Implemented naively, they can hurt you more than having none at all.

What I found

The nightly job exported the entire database and stored the result as-is. That database includes a settings table, and the settings table holds provider keys and access tokens.

So every night, I was copying my secrets into a place I had never treated as a place for secrets.

Why it happened

The export was technically correct. It dumped everything, exactly as instructed, and "everything" happened to include values that should never leave the database in the first place.

I keep running into this pattern: the tool carries out the request to the letter, while the flaw lives in the request itself.

What I did

I added a mandatory scrubber to the export path: a step that runs over the output before it is stored and replaces sensitive values with a fixed marker.

Mandatory is the load-bearing word here. Every new export path passes through the same step automatically; otherwise safety would hang on whoever writes the next path remembering to add it.

The rule I took from it

Assume the backup will be read. The reader does not have to be an attacker. A collaborator might open it while helping with a task, or a copy might land on a laptop and then sit in a folder everyone forgot about.

A backup is also more sensitive than production itself, because it packs everything into one file that travels easily.

What to do right now

Open your most recent backup and search it for key, token or secret. If you find anything, you are standing where I stood, and the next step is clear: put the scrubber in the export path before tonight's run.