# Security and Privacy

Protect users and project integrity from the first design. Security is a set of product rules, technical controls, operating procedures, and verified recovery—not a final checklist item.

[Kit README](README.md) · [Project Overview](Project%20Overview.md) · [PRD](Full%20PRD%20Template.md) · [Master Build Prompt](Master%20Build%20Prompt.md) · [Completion Checklist](Project%20Completion%20Checklist.md)

## Data Inventory

| Data | Purpose | Classification | Access | Retention | Delete/Export |
| --- | --- | --- | --- | --- | --- |
| [FIELD OR RECORD] | [NECESSARY PURPOSE] | [Public/Internal/Personal/Sensitive] | [ROLES/SYSTEMS] | [PERIOD] | [BEHAVIOR] |

If a field has no clear purpose or owner, do not collect it. Never put secrets, access tokens, payment details, or sensitive personal data into sample fixtures, client bundles, analytics properties, or AI prompts unless the approved design explicitly requires safe handling.

## Permission Matrix

| Action | Visitor | User | Owner/Manager | Operator/Admin |
| --- | --- | --- | --- | --- |
| View own/current object | [Y/N] | [RULE] | [RULE] | [JUSTIFIED RULE] |
| Create | [RULE] | [RULE] | [RULE] | [RULE] |
| Change/delete | No | [OWN OBJECT RULE] | [SCOPE RULE] | [APPROVAL/AUDIT] |
| Export or perform consequential action | No | [RULE] | [RULE] | [EXPLICIT AUTH + AUDIT] |

## Domain Controls

1. **Server-side contact validation.** Define prevention, detection, test, alert owner, and recovery.
2. **Rate limiting and bot protection.** Define prevention, detection, test, alert owner, and recovery.
3. **Safe HTML rendering.** Define prevention, detection, test, alert owner, and recovery.
4. **Security headers.** Define prevention, detection, test, alert owner, and recovery.
5. **Least-data analytics.** Define prevention, detection, test, alert owner, and recovery.

## Threat and Abuse Review

| Scenario | Asset at Risk | Prevention | Detection | Recovery | Owner |
| --- | --- | --- | --- | --- | --- |
| unclear positioning | [DATA/USER/SERVICE] | [CONTROL] | [SIGNAL] | [ACTION] | [OWNER] |
| oversized media | [DATA/USER/SERVICE] | [CONTROL] | [SIGNAL] | [ACTION] | [OWNER] |
| broken mobile navigation | [DATA/USER/SERVICE] | [CONTROL] | [SIGNAL] | [ACTION] | [OWNER] |
| forms that silently fail | [DATA/USER/SERVICE] | [CONTROL] | [SIGNAL] | [ACTION] | [OWNER] |
| missing page titles and alt text | [DATA/USER/SERVICE] | [CONTROL] | [SIGNAL] | [ACTION] | [OWNER] |

Also review broken access control, malicious input, dependency compromise, credential leakage, automated abuse, data scraping, unsafe uploads, replay/duplicate actions, denial of service, operator mistakes, and backup exposure. Adapt relevance to the platform.

## Engineering Requirements

- [ ] Secrets are server-side or stored in an operating-system credential facility; none are committed.
- [ ] Inputs are validated at trust boundaries and outputs are encoded for their context.
- [ ] Authentication sessions, password resets, and account deletion use established secure mechanisms.
- [ ] Authorization is tested for every sensitive object and operation.
- [ ] Dependencies are pinned, reviewed, and updated through a controlled process.
- [ ] Logs are structured, access-controlled, retention-limited, and redacted.
- [ ] Backups are protected and restore is tested.
- [ ] Security headers, transport protection, signing, or sandboxing are applied as appropriate to the platform.
- [ ] A vulnerability reporting and incident response owner is named.

## Release Gate

No launch with an unresolved high-impact path that can expose protected data, cross a tenant or user boundary, perform an unapproved consequential action, corrupt durable records, or leak a secret. Record accepted lower risks with owner, expiry date, and mitigation plan.