---
name: authz-idor-audit
description: >
  Autorisierung einer App systematisch prüfen: Rollenmatrix aufstellen, jede Route gegen
  Rollen und Objektbesitz abgleichen, IDOR- und Rechte-Lücken finden und als Tests abbilden.

  TRIGGER WENN der User sagt: "IDOR", "Berechtigungen prüfen", "Rollen prüfen",
  "wer darf was", "Rollenmatrix", "authz audit", "/authz-idor-audit", oder wenn neue
  Endpunkte, Rollenänderungen, SSO/OIDC oder Team-/Mehrbenutzer-Funktionen dazukommen.

  Ergebnis: Rollenmatrix, gefundene Lücken, neue Tests (erst rot, dann grün).
---

# authz-idor-audit

Login allein schützt nichts: die häufigste Lücke in KI-Code ist „eingeloggt, aber sieht
fremde Objekte“ (IDOR). Dieser Skill macht die Rechte explizit und testbar.

## Ablauf

### 1. Routen und Rollen erfassen
- Alle Routen auflisten: FastAPI aus `app.openapi()["paths"]` (nicht aus `app.routes`,
  eingebundene Router fehlen dort je nach Version), Express aus dem Routen-Inventar der
  Baseline (`tests/security/routes.ts`) oder per `grep -rn "router\.\(get\|post\|put\|patch\|delete\)"`.
- Rollen und Identitätsquelle aus dem Code ermitteln (Session, JWT, Proxy-Header, OIDC-Claims).

### 2. Rollenmatrix aufstellen
Pro Ressource und Aktion: wer darf? Zellen: `alle`, `eigene`, `Team`, `Admin`, `—`.
```
| Ressource      | Aktion | Mitarbeiter | Projektleiter | Admin |
|----------------|--------|-------------|---------------|-------|
| Projekt        | lesen  | zugewiesene | eigene        | alle  |
| Projekt        | ändern | —           | eigene        | alle  |
| Zuweisung      | anlegen| —           | eigene Proj.  | alle  |
| Mitarbeiterdaten | lesen | sich selbst | Team        | alle  |
```
Unklare Zellen **nicht raten**, sondern dem User als Frage vorlegen. Die Matrix ist eine
fachliche Entscheidung.

### 3. Code gegen Matrix prüfen
Pro Route: Wo genau wird die Matrix-Zelle durchgesetzt (Datei:Zeile)? Typische Lücken:
- Objekt per ID geladen, Besitz nicht geprüft (lesen, ändern, löschen getrennt prüfen).
- Liste ungefiltert, Filter nur im Frontend.
- Fremdschlüssel im Body (`project_id`, `owner`, `leader`, `role`) wird übernommen.
- Rechte nur im UI ausgeblendet, API offen.
- Prüfung im GET vorhanden, im PATCH/DELETE vergessen.

### 4. Tests schreiben (zuerst rot)
Für jede Lücke und jede Matrix-Zelle mit Einschränkung ein Test mit **zwei** synthetischen
Nutzern derselben Rolle (A besitzt, B nicht):
- B liest/ändert/löscht Objekt von A → 403 oder 404
- Liste von B enthält kein Objekt von A
- B setzt im Body fremde `owner`/`project_id` → 403/422
Bei eingebauter Baseline: Fälle in `IDOR_CASES` bzw. `MASS_ASSIGNMENT_CASES` der
`conftest.py` / `security.config.ts` ergänzen. Test laufen lassen, **roten Lauf zeigen**,
dann Code fixen, dann grün.

### 5. Gegenprobe
Eine der neuen Prüfungen im Code kurz auskommentieren → mindestens ein Test muss rot
werden → zurücknehmen. Ohne diesen Nachweis gilt der Test als unbewiesen.

## Ausgabe
1. Rollenmatrix (mit offenen Fragen markiert)
2. Lückentabelle: `| Route | Methode | Matrix sagt | Code macht | Datei:Zeile | Prio |`
3. Liste der neuen Tests + Ergebnis roter/grüner Lauf + Gegenprobe