# 🔒 Security Policy

## Sicherheitsarchitektur

Dieses Template wurde mit einem **Security-First-Ansatz** entwickelt und ist optimiert für den Einsatz mit Gitea Actions und anderen CI/CD-Systemen.

## 🛡️ Implementierte Sicherheitsmaßnahmen

### Container Security

#### Non-Root Container (✅ Kritisch)
Alle Container laufen als nicht-privilegierte Benutzer:

- **Application Container**: UID 1000 (`appuser`)
- **PostgreSQL Container**: UID 70 (Standard postgres-User)
- **Frontend Dev Container**: UID 1000 (`node`)

**Warum wichtig?**: Container die als root laufen, können bei einem Breakout den Host kompromittieren.

#### Security Options
```yaml
security_opt:
  - no-new-privileges:true  # Verhindert Privilege Escalation
cap_drop:
  - ALL                     # Entfernt alle Linux Capabilities
cap_add:
  - NET_BIND_SERVICE        # Nur benötigte Capabilities
```

#### Resource Limits
```yaml
resources:
  limits:
    cpus: '2.0'
    memory: 2G
```
Verhindert DoS-Angriffe durch Resource-Exhaustion.

### Network Security

#### Isolierte Datenbank
- PostgreSQL ist **nicht** nach außen exponiert
- Nur über internes Docker-Netzwerk erreichbar
- Für lokales Debugging kann der Port bei Bedarf freigegeben werden

#### CORS-Whitelist
```typescript
const allowedOrigins = [
  'https://your-domain.com',
  'https://www.your-domain.com'
];
```
Nur explizit erlaubte Origins dürfen API-Requests durchführen.

### Application Security

#### Security Headers (Helmet.js)
- `Content-Security-Policy`: Verhindert XSS-Angriffe
- `Strict-Transport-Security`: Erzwingt HTTPS
- `X-Content-Type-Options`: Verhindert MIME-Sniffing
- `X-Frame-Options`: Verhindert Clickjacking
- `Permissions-Policy`: Kontrolliert Browser-Features

#### Input-Validierung
Alle API-Endpoints validieren ihre Inputs:

```typescript
app.post('/api/print', [
  body('photoId').isInt({ min: 1 }),
  body('copies').isInt({ min: 1, max: 100 }),
  validateRequest
], handler);
```

#### Request Size Limits
```typescript
app.use(express.json({ limit: '10mb' }));
```
Verhindert DoS durch große Payloads.

### Database Security

#### Authentifizierung
- Verwendet `scram-sha-256` statt MD5
- Keine Default-Passwörter (müssen gesetzt werden)
- Sichere Passwortgenerierung empfohlen

#### Secrets Management
- Keine Secrets im Code
- `.env` in `.gitignore`
- `.env.example` als Vorlage

## 🔍 CI/CD Security Scans

### Automatische Scans in Gitea Actions

#### 1. Quellcode-Scan
```bash
trivy fs --severity CRITICAL,HIGH --exit-code 1 .
```
Scannt auf Schwachstellen in Dependencies.

#### 2. Docker Image-Scan
```bash
trivy image --severity CRITICAL,HIGH $IMAGE_NAME
```
Scannt fertige Docker Images.

#### 3. IaC-Scan
```bash
trivy config --severity CRITICAL,HIGH .
```
Prüft Dockerfiles und docker-compose.yml.

#### 4. Automatische Fixes
Bei gefundenen Schwachstellen:
- Führt `npm audit fix` aus
- Erstellt automatischen Commit
- Baut neue Docker Images

### Tägliche Security-Scans
- Laufen täglich um 6:00 UTC (Cron-Job)
- Prüfen auf neue Schwachstellen
- Erstellen automatische Updates

## ⚠️ Bekannte Einschränkungen

### Kein Rate Limiting
Rate Limiting ist **absichtlich nicht** implementiert, da es in Development-Umgebungen Probleme verursachen kann.

**Für Production**: Implementiere Rate Limiting über:
- Traefik/Nginx Rate Limiting
- express-rate-limit Middleware
- CloudFlare oder ähnliche Services

### Keine End-to-End Verschlüsselung
Das Template setzt voraus, dass TLS/HTTPS auf Reverse-Proxy-Ebene (z.B. Traefik) implementiert wird.

## 🚨 Vulnerability Reporting

### Sicherheitslücken melden

Wenn du eine Sicherheitslücke in diesem Template findest:

1. **NICHT** als öffentliches GitHub Issue melden
2. Sende eine E-Mail an: [security@your-domain.com]
3. Beschreibe das Problem detailliert
4. Füge PoC hinzu (falls vorhanden)

### Response Timeline
- **Initial Response**: Innerhalb von 48 Stunden
- **Fix & Patch**: Abhängig von Severity (Critical: 7 Tage, High: 30 Tage)
- **Public Disclosure**: Nach Patch-Veröffentlichung

## ✅ Security Checklist vor Deployment

### Pflicht (vor jedem Deployment)
- [ ] `.env` Datei erstellt und ausgefüllt
- [ ] Starke Secrets generiert (min. 32 Zeichen)
- [ ] `NODE_ENV=production` gesetzt
- [ ] CORS-Origins auf Production-Domains angepasst
- [ ] PostgreSQL-Passwort geändert
- [ ] JWT-Secret geändert

### Empfohlen
- [ ] TLS/HTTPS konfiguriert (Traefik mit Let's Encrypt)
- [ ] Monitoring & Alerting eingerichtet
- [ ] Backup-Strategie implementiert
- [ ] Secrets in Vault oder Secret Manager
- [ ] Logging konfiguriert (keine Secrets in Logs!)
- [ ] Firewall-Regeln geprüft

### Optional (Production)
- [ ] Rate Limiting aktiviert
- [ ] WAF (Web Application Firewall) vorgeschaltet
- [ ] DDoS-Protection aktiv
- [ ] Penetration Testing durchgeführt
- [ ] Security Headers im Reverse Proxy verdoppelt

## 📚 Weitere Ressourcen

### Standards & Best Practices
- [OWASP Top 10](https://owasp.org/www-project-top-ten/)
- [OWASP API Security Top 10](https://owasp.org/www-project-api-security/)
- [CIS Docker Benchmark](https://www.cisecurity.org/benchmark/docker)
- [Node.js Security Best Practices](https://nodejs.org/en/docs/guides/security/)

### Tools
- [Trivy Scanner](https://github.com/aquasecurity/trivy)
- [npm audit](https://docs.npmjs.com/cli/v8/commands/npm-audit)
- [Snyk](https://snyk.io/)
- [OWASP ZAP](https://www.zaproxy.org/)

## 📝 Changelog

### Version 1.0.0 (2024)
- ✅ Non-root Container für alle Services
- ✅ Security Headers mit Helmet.js
- ✅ Input-Validierung mit express-validator
- ✅ CORS-Whitelist
- ✅ Resource Limits
- ✅ Isolierte PostgreSQL-Datenbank
- ✅ Automatische Security-Scans in CI/CD
- ✅ scram-sha-256 Authentifizierung für PostgreSQL

## 📄 License

Dieses Security-Dokument ist Teil des Full Stack TypeScript Templates und unterliegt der MIT-Lizenz.