Security policy

Status: Accepted · Version: 0.1

This policy is binding on every repository. Threat scenarios are in architecture/threat-model.md.

Prohibited data

Titip must not request, accept, or persist:

passwords
PINs
one-time passcodes (except the short-lived login OTP that auth verifies and immediately discards)
CVVs or full payment card numbers
recovery phrases and seed phrases
private keys and keystore files
any other authentication secret for a third-party system

Login OTPs are a transit secret for Titip’s own auth module. They are not vault content. They must not be logged or audited in raw form.

Access

Default deny between roles. Owner, trusted contact, recipient, and reviewer credentials are not interchangeable.
Recipient authorization is an explicit vault list (ADR-003).
Employees do not get standing plaintext access. A production break-glass procedure is required before launch and does not exist in the prototype.
Administrative approval of a release must include the evidence list. An approval event without evidence codes is invalid.

Application rules

Encrypt restricted fields (ADR-006).
Do not put restricted fields in URLs, notifications, analytics, or client crash reports.
Session tokens and recipient tokens are different types. A bug that accepts one where the other is required is a release blocker.
Dependencies that send messages are allowed only inside the notification adapter.

Vulnerability handling

Until a security repository exists, reports are handled privately by the maintainers of this organisation. Do not file public issues that include exploit detail against a running environment. The prototype has no production tenants; still do not publish secrets in sample data.

Secure development

Contracts change in this repository before code relies on them.
A change to release, encryption, or auth requires an ADR or a spec revision in the same pull request.
Sample fixtures use fake names and fake institutions. They never use real credentials, even “expired” ones.