---
name: warden-security
description: Security and privacy by design — GDPR principles, secure coding defaults, and data handling rules
user-invokable: true
---

# Security & Privacy by Design

> **Policy Area:** Security & Privacy
> **Version:** 1.0
> **Status:** Active
> **Enforcement:** Advisory (human-approved deviations only)
> **Purpose:** Ensure every feature handles data responsibly and follows secure coding defaults

---

## 1. Privacy by Design (GDPR Article 25)

All features touching user or personal data MUST follow these principles by default. Deviate only after flagging to the human and getting explicit approval.

| Principle | Rule |
|-----------|------|
| **Data Minimisation** | Only collect fields that are strictly necessary |
| **Purpose Limitation** | Data used only for its stated purpose |
| **Storage Limitation** | Define retention period; don't keep data forever |
| **Accuracy** | Provide mechanisms to correct/update personal data |
| **Integrity & Confidentiality** | Encrypt at rest and in transit where appropriate |
| **Accountability** | Audit trails for personal data access/changes |

### When to Apply

- **During PROPOSE/PLAN:** Flag any personal data fields in the data model and justify each one. If a field isn't strictly necessary, remove it.
- **During BUILD:** Default to pseudonymisation where possible. No unnecessary PII. Hash or encrypt sensitive fields.
- **During VERIFY:** Check that no personal data is logged, leaked in error messages, or exposed in API responses beyond what's needed.

---

## 2. Security by Design

These are non-negotiable defaults. Opt-out requires explicit human justification.

### Secrets Management
- No hardcoded secrets — `.env` only, `.env` in `.gitignore`
- Never log secrets, tokens, or credentials
- Never commit secrets — GitGuardian / TruffleHog enforced in CI
- Environment variables for all configuration that varies between environments

### Database & Queries
- No raw SQL queries without explicit human approval — use ORM
- Parameterised queries only (no string interpolation in SQL)
- Validate and sanitise all user input before it reaches the database

### Authentication & Authorization
- Auth on every endpoint by default — opt-out requires justification
- Password hashing with bcrypt/argon2 (never plain text, never MD5/SHA1)
- Session tokens: secure, httpOnly, sameSite flags
- Role-based access control: principle of least privilege

### Web Security
- CSRF protection on all state-changing endpoints
- CORS: whitelist specific origins, never `*` in production
- Rate limiting on authentication and public-facing endpoints
- Input validation on all user-facing inputs (length, type, format)
- Output encoding to prevent XSS

### Dependencies
- Dependencies must pass security audit before merge (`pip-audit`, `npm audit`)
- Pin dependency versions in production
- Review changelogs before major version upgrades

---

## 3. Security Checklist for New Features

When building a feature that handles user data, authentication, or external APIs, verify:

- [ ] No new PII fields without justification (Privacy §1)
- [ ] Secrets in `.env`, not in code or config files
- [ ] Auth applied to new endpoints
- [ ] Input validated at system boundaries
- [ ] No raw SQL — ORM only
- [ ] Dependencies audited
- [ ] Error messages don't leak internal details
- [ ] Personal data not logged or exposed unnecessarily
- [ ] Retention period defined for any stored data

---

*This skill should be invoked when building features that touch user data, authentication, or external services.*