Rotate the CRAFT_SECURITY_KEY committed in .env.docker.example #44

New issue

Open

opened 2026-08-21 23:25:47 +00:00 by Phil · 0 comments

Phil commented

2026-08-21 23:25:47 +00:00

Owner

Symptom

.env.docker.example is tracked in git and carries a real CRAFT_SECURITY_KEY and CRAFT_APP_ID where placeholders belong. The same key is in the untracked .env / .env.production, so what is in the repository is the key production actually runs on.

Craft derives cookie and CSRF token signing, and the encryption of stored secrets, from this key. Anyone with read access to the repo — or to any clone, fork, backup or CI cache of it — holds it.

Found while deploying an unrelated site to the same host; not caused by that work.

What needs to happen

Generate a new security key and roll it into the running deployment.
Replace the values in .env.docker.example with obvious placeholders.
Decide whether the history needs rewriting or whether rotation is sufficient — rotation makes the leaked value useless, which is usually the proportionate answer for a private repo.

Also worth a look while in there: .env / .env.production carry a MATOMO_API_TOKEN in plain text. That one is untracked, so it is not in git, but it is a full-access Matomo token sitting in the working tree.

Acceptance criteria

Production runs on a key that has never been committed
.env.docker.example contains no real credential
Sessions/CSRF still work after the rotation (a key change invalidates existing sessions — expect one forced re-login)

## Symptom `.env.docker.example` is tracked in git and carries a real `CRAFT_SECURITY_KEY` and `CRAFT_APP_ID` where placeholders belong. The same key is in the untracked `.env` / `.env.production`, so what is in the repository is the key production actually runs on. Craft derives cookie and CSRF token signing, and the encryption of stored secrets, from this key. Anyone with read access to the repo — or to any clone, fork, backup or CI cache of it — holds it. Found while deploying an unrelated site to the same host; not caused by that work. ## What needs to happen 1. Generate a new security key and roll it into the running deployment. 2. Replace the values in `.env.docker.example` with obvious placeholders. 3. Decide whether the history needs rewriting or whether rotation is sufficient — rotation makes the leaked value useless, which is usually the proportionate answer for a private repo. Also worth a look while in there: `.env` / `.env.production` carry a `MATOMO_API_TOKEN` in plain text. That one is untracked, so it is not in git, but it is a full-access Matomo token sitting in the working tree. ## Acceptance criteria - [ ] Production runs on a key that has never been committed - [ ] `.env.docker.example` contains no real credential - [ ] Sessions/CSRF still work after the rotation (a key change invalidates existing sessions — expect one forced re-login)

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

Phil/philflow.io#44

No description provided.

Rows
Columns