Secrets, encryption and personal data
🎯You'll be able to
Keep secrets out of code, protect data in transit and at rest, store passwords correctly, and limit what personal data you keep and log.
🏠The everyday picture
A bank keeps the locker master key in a safe, not taped under the counter. Your locker's contents are listed only by number in the visitor register, never described.
📘What it really is
- Secrets (database passwords, API keys, client secrets, webhook secrets):
- load them from environment settings or a secret manager, never commit them; keep a
.env.examplewith practice values only (as the kit does); - give each secret the least privilege it needs and rotate it if exposed (Module 77);
-
scan repositories for secrets before pushing.
-
In transit: HTTPS (TLS) everywhere, including between your own services where the network isn't fully trusted.
-
At rest: encrypt disks and backups (cloud databases do this by default); encrypt especially sensitive fields (such as Aadhaar numbers, if you must store them at all) with keys held separately.
-
Passwords, if you store them: a slow, salted password hash designed for it: Argon2id, scrypt or bcrypt. Never plain text, MD5, SHA-256 alone, or reversible encryption.
-
Personal data (Module 79, and India's Digital Personal Data Protection Act, 2023): collect only what you need, explain why, keep it only as long as needed, and keep it out of logs. Log IDs, not phone numbers, addresses or tokens.
📝A worked example
A log line from the starter, during an error:
POST /v1/orders body={"phone":"+91 90000 00042","address":"12 Laxmi Road"} auth=Bearer eyJhbGciOi...
Problems: a phone number, an address and a full bearer token (which anyone reading the logs could reuse until it expires).
Fixed log line from the finished kit's error handler:
2026-11-01T07:12:03.120Z POST /v1/orders request_id=7f3a customer_id=1 error=<message and stack>
Expected outcome: logs that help debugging with IDs and timings, but contain no secrets, tokens or personal details.
🌍Where it's used
- Every deployment, through environment settings and secret managers.
- Security and privacy reviews, and responses to data requests from customers.
- Incident response, when a key leaks and must be rotated in minutes.
📝Case scenario
A developer commits a .env file with the production database password to a public repository "for a minute". Automated scanners find it
within hours, and the database is copied. Deleting the commit doesn't help: the password must be rotated immediately, access logs
checked, and a pre-commit secret scan and .gitignore entry added.
🖱️Try it
Search the kit's files for anything that looks like a secret (grep -ri "secret\|password" --include=*.js .). For each hit, decide:
practice value, real secret, or neither. Then write a logging rule for TiffinBox: which fields may be logged, which may not. Success:
every hit is a labelled practice value, and your rule names at least four fields to keep out of logs.
⚠️Common mistakes
- Secrets in code or committed files. Sign: keys in the repository history. Fix: environment or secret manager; rotate anything exposed.
- Fast hashes for passwords. Sign:
sha256(password)or MD5. Fix: Argon2id, scrypt or bcrypt with a salt. - Personal data and tokens in logs. Sign: phone numbers, addresses or
Authorizationheaders in log lines. Fix: log IDs and redact sensitive fields.
🛠️For your project
The project pages refuse evidence text that looks like a secret; Project 1's marking guide has a safety item for secrets in code and logs.
✅Quick check
Which hashing methods suit stored passwords?
Show the answer
Slow, salted password hashes: Argon2id, scrypt or bcrypt.
A secret was committed and then deleted in the next commit. Is it safe?
Show the answer
No: it's still in history and may already be copied. Rotate it.