Learn how to classify, minimize, store, redact, rotate, and delete sensitive data in Clojure systems without letting logs, queues, caches, and support tooling become accidental leak paths.
Sensitive data: Any value whose exposure, corruption, or misuse would materially harm a user, tenant, operator, or organization.
That includes more than passwords and card numbers. In real Clojure systems it often includes:
The main mistake is treating sensitive data as a database-storage problem only. Most leaks happen in motion or in tooling:
Before protecting data, decide whether you should store it at all.
Ask:
Data minimization is often the strongest protection because the safest secret is the one you never collect or retain.
Sensitive data can exist:
Each state needs a different control surface. Encrypting the database does not help if the value still appears in application logs or queue dead-letter payloads.
The simplest high-value control is often structured redaction:
1(defn redact-customer [customer]
2 (-> customer
3 (update :email #(when % "[redacted-email]"))
4 (update :phone #(when % "[redacted-phone]"))
5 (update :payment/token #(when % "[redacted-token]"))
6 (dissoc :ssn)))
Use redaction before:
That is safer than trusting every downstream consumer to remember what not to print.
A password-reset token, API key, or signing key is not just “another string field.” It has a different lifecycle:
Treating secrets like ordinary config or customer profile data is how secrets end up in Git history, screenshots, or monitoring systems.
Encryption is useful, but only when it is paired with sound key management. The real control set is:
The application boundary around decryption is usually more important than the raw encryption primitive.
One common failure mode is copying production-like sensitive data into lower environments. Safer approaches include:
The more people and tools that can touch an environment, the lower the bar should be for redaction and minimization.
Sensitive data that never leaves the system is still a risk if it remains forever. Review:
Long-term retention should be explicit, not accidental.
This is one of the most common “we encrypted everything” misconceptions.
Access to decrypt or export sensitive data should be narrow and purposeful.
Staging and developer environments often have weaker controls and more broad access.
Many leaks happen outside the main request/response path.
Classify sensitive values early, store less of them, redact aggressively outside the narrow business need, and treat logs, queues, exports, and support tools as first-class exposure surfaces. Encrypt where appropriate, but remember that key management, access review, and deletion policy are just as important. In Clojure, a data-oriented architecture makes these flows easier to trace. Use that clarity to constrain exposure instead of letting every map travel everywhere unchanged.