Who this is for. Everyone who commits to a theme repository, and whoever reviews their changes. Afterwards you can recognise a secret before it is committed, keep the repository's ignore list honest, and handle one that has already been committed in the right order.
Why a private repository is not private enough
A repository is copied to every developer's laptop, every contractor's, every build server and every backup, and a commit stays in the history of all of them for good. Deleting the file in a later commit removes it from the latest version only. A secret committed once has to be treated as known.
The categories
| What | Shapes it takes | Where it belongs |
|---|---|---|
| Provider API keys | Payment gateway secrets, CRM and marketing tokens, server-side map or geocoding keys, written into a template, a script or a config file | The module's settings in the admin |
| Mail-service credentials | A mail provider's API key in a tracked .settings.json | The mail settings in the admin |
| Deploy credentials | An SFTP host, user name, private-key path and passphrase in a tracked upload script such as .build/ssh-config.js, even one whose fields are empty today | The developer's own machine, in a file the repository ignores |
| Environment files | .env, .env.*, .environment.json | The server or the developer's machine; never the repository |
| Local IDE settings | .idea/, .vscode/, including deployment and SFTP settings saved there | The developer's machine |
| Platform credentials | A Core dna API key, an OAuth token or a webhook token copied into a script or a note | A secret store or the environment of the program that uses it |
A site's .settings.json deserves its own mention. It overrides the admin's settings, and the platform's code describes it as a file kept out of the repository and controlled by system administrators. Several repositories track it all the same, because it is also where a site's template engine can be set, and two production repositories track a mail provider's credentials in it. If yours is tracked, keep only non-secret values in it.
Site data is not a place for secrets either: whatever a template prints from it is public, and the API returns it to any authenticated reader.
Keys that a browser must see, such as a maps key used from JavaScript, end up in the page source anyway. Restrict them to your domains at the provider instead of trying to hide them.
An ignore list to start from
Most production repositories ignore node_modules/ and .idea; few ignore .env. Add the missing lines now, before anyone needs them: