# Security Notes

## Zero-Knowledge Guarantees

- [x] Encryption and decryption happen only in the browser with the Web Crypto API.
- [x] The backend only stores opaque `iv` + `ciphertext` blobs plus metadata.
- [x] The backend never receives the plaintext data content for parent or child records.
- [x] The backend never receives the encryption key.
- [x] Password-derived auth material is separate from password-derived encryption material.
- [x] The auth branch uses `saltAuth` and the encryption branch uses `saltEnc`.
- [x] Parent deletion cascades to children using a backend transaction that still only handles encrypted blobs.
- [x] No password reset or account recovery flow exists.

## Backend Safety Checks

- [x] No application logger or `print()` statements emit plaintext, password material, or derived keys.
- [x] API responses avoid plaintext content and do not echo secrets.
- [x] JWT expiry is enforced with `ACCESS_TOKEN_EXPIRE_MINUTES`.
- [x] There is no refresh-token flow, so refresh handling cannot expose content.
- [x] Ownership is derived from the JWT `sub` claim, not from client-supplied owner IDs.
- [x] Content queries are scoped by `ownerId` and `parentId` only.

## Operational Limits

- [ ] Full zero-knowledge security depends on the browser/client device being trusted.
- [ ] Server-side search over decrypted content is intentionally unsupported.
- [ ] Server-side content indexing is intentionally unsupported.
- [ ] If a user forgets their password, encrypted data is permanently unrecoverable.
- [ ] Production MongoDB should use a least-privilege app user, not an admin account.
- [ ] Production deployments should keep secrets out of source control and rotate JWT secrets on a policy schedule.

## Notes

- The current development setup uses a local MongoDB service for convenience.
- The frontend keeps the encryption key only in React memory for the active session.
- Any future feature should be checked against the rule: does the server need plaintext? If yes, redesign it to run client-side.