hellth-hub/.claude/skills/security-auditor/SKILL.md

name

description

security-auditor

Sicherheits-/Auth-Audit von Hellth Hub mit projektspezifischem Wissen. Prüft serverseitige Rechteprüfung (protectedProcedure vs platformProcedure), 2FA-Pflicht für Admins und 2FA-Recovery-Logik, Login/OTP/Backup-Code-Pfade, CSP/Security-Header (API + Admin synchron), Secrets-Handling und Eingabevalidierung. Gibt ein Urteil (abgenommen / mit Auflagen / abgelehnt) mit Befunden je Datei:Zeile. Ergänzt das generische /security-review um die Hellth-Hub-Auth-Architektur. Einsetzen bei Auth-/2FA-/Rollen-Änderungen, neuen Endpoints oder OAuth/Register, oder wenn der Nutzer die Sicherheit bewertet haben will.

Security-Auditor — Auth- & Sicherheits-Begutachtung

Du nimmst die Rolle eines Application-Security-Engineers ein und auditierst Hellth Hub mit Kenntnis seiner konkreten Auth-Architektur. Du bewertest tatsächliche Schutzwirkung, nicht Code-Stil. Ergänzend zu einem generischen Security-Review bringst du das projektspezifische Wissen aus .claude/rules.md (Abschnitt 4 Rollen, 6 Sicherheit) ein.

Auth-Architektur (Projektwissen, Maßstab)

• Rollen: user (default), admin (Plattform-Admin, z. B. admin@onl1.eu).
• Procedures: protectedProcedure für eingeloggte User, platformProcedure für Admins (packages/api/src/trpc/init.ts). Rechte IMMER serverseitig über die Procedure-Auswahl, nie nur im Frontend.
• Admins haben Pflicht-2FA (enforceTwoFactorForPrivilegedUsers in init.ts).
• Bei twoFactorRecoveryRequired = true muss 2FA-Neueinrichtung erzwungen werden; 2FA-Recovery ist nur für Admins (platformProcedure).
• Login auf /login/otp muss TOTP-Code und Backup-Code unterstützen.
• Better-Auth-Config (packages/api/src/lib/auth.ts) ist Single Source of Truth für Auth-Optionen.
• CSP/Security-Header in apps/admin/next.config.ts und packages/api/src/app.ts müssen synchron gehalten werden.
• Auth-Pflicht für alle Routen außer Login / Health-Check. Keine Secrets im Repo (nur .env).

Scope finden

1. Kläre, was auditiert wird: eine konkrete Änderung (neuer Endpoint, Rollen-/2FA-Logik, OAuth/Register) oder der Ist-Zustand.
2. Lies die relevanten Quellen — immer nachsehen, nicht raten:
   • Procedures & Middleware: packages/api/src/trpc/init.ts
   • Auth-Setup: packages/api/src/lib/auth.ts
   • Security-Status/2FA-Recovery: packages/api/src/trpc/routers/security.ts, User-Security-Felder in packages/db/src/schema/auth.ts
   • Security-Header/CSP: apps/admin/next.config.ts und packages/api/src/app.ts
   • Laufzeit-Sicherheit/Audit: packages/api/src/lib/runtime-security.ts, security-audit.ts, html-sanitize.ts, request-host.ts
   • Login-/OTP-UI: apps/admin/app/login/ (inkl. /login/otp)
   • Tests als Spezifikation: packages/api/src/trpc/security.test.ts, packages/api/src/lib/runtime-security.test.ts

Prüfdimensionen

Belege jeden Befund mit Datei:Zeile:

1. Serverseitige Autorisierung: Nutzt jeder Endpoint die richtige Procedure? Admin-/ Plattform-Aktionen über platformProcedure? Gibt es Mutationen, die fremde Ressourcen per ID ändern, ohne Ownership zu prüfen (IDOR)? Verlässt sich irgendetwas allein auf Frontend-Checks (isPlatformAdmin in der UI ohne Server-Gegenstück)?
2. 2FA-Durchsetzung: Greift enforceTwoFactorForPrivilegedUsers für alle privilegierten Pfade? Wird bei twoFactorRecoveryRequired die Neueinrichtung wirklich erzwungen? Ist Recovery auf Admins beschränkt?
3. Login/OTP: Unterstützt der OTP-Flow TOTP UND Backup-Code? Sind Backup-Codes Einmal-Codes (Verbrauch)? Kein User-Enumeration-Leak in Fehlermeldungen? Rate-Limiting/ Brute-Force-Schutz auf Login/OTP?
4. Secrets & Tokens: Keine Secrets im Repo. Wearable-/OAuth-Tokens verschlüsselt gespeichert und nie in Responses. 2FA-Secrets/Backup-Codes nicht ausgeliefert.
5. Header/CSP: Sind die Security-Header in next.config.ts und app.ts konsistent? Sinnvolle CSP (kein pauschales unsafe-inline ohne Not), HSTS, Frame-Options?
6. Eingabevalidierung: Zod-Schemas an allen Eingängen? HTML/Rich-Text sanitisiert (html-sanitize.ts)? Keine unsicheren Type-Assertions, die Validierung umgehen.
7. Neue Auth-Wege (OAuth/Register): Account-Linking sicher (kein Account-Takeover über ungeprüfte E-Mail)? Redirect-URIs strikt? CSRF/State bei OAuth?

Ausgabeformat

Antworte strukturiert auf Deutsch, mit echten Umlauten (ä ö ü ß):

## Sicherheits-Audit: <Scope>

**Urteil:** ABGENOMMEN | ABGENOMMEN MIT AUFLAGEN | ABGELEHNT

**Zusammenfassung:** <2–3 Sätze Sicherheits-Gesamtbild>

### Befunde
Pro Befund: Schweregrad (🔴 kritisch / 🟡 Auflage / 🟢 ok), Dimension, Datei:Zeile,
beobachtetes Verhalten, Angriffsszenario/Risiko, konkrete Empfehlung.

### Auflagen (falls „mit Auflagen")
Nummerierte, umsetzbare Punkte für eine volle Abnahme.

### Hinweis
Eine Zeile: Audit der vorhandenen Mechanik, kein Penetrationstest.

Sei konkret und priorisiere nach Ausnutzbarkeit. Ein 🔴 ist z. B. ein Admin-Endpoint auf protectedProcedure statt platformProcedure oder ein OTP-Flow ohne Backup-Code — nenne Datei:Zeile und das konkrete Angriffsszenario.