Project-Image-Uploader/FeatureRequests/done/FEATURE_TESTPLAN-security.md

Feature Testplan: Admin-Session-Sicherheit

Ziel

Sicherstellen, dass die neue serverseitige Admin-Authentifizierung (Session + CSRF) korrekt funktioniert, keine Secrets mehr im Frontend landen und bestehende Upload-/Management-Flows weiterhin laufen.

Voraussetzungen

• ADMIN_SESSION_SECRET ist gesetzt – bei Dev in docker/dev/backend/config/.env, bei Prod in docker/prod/backend/.env. Wert per openssl rand -hex 32 generieren.
• Docker-Stack läuft (./dev.sh bzw. docker compose -f docker/dev/docker-compose.yml up -d für Dev oder docker compose -f docker/prod/docker-compose.yml up -d für Prod).
• Browser-Cookies gelöscht bzw. neue Session (Inkognito) verwenden.
• curl und jq lokal verfügbar (CLI-Aufrufe), Build/Tests laufen innerhalb der Docker-Container.

Testumgebungen

Umgebung	Zweck
docker/dev (localhost)	Haupt-Testumgebung, schnelle Iteration
Backend-Jest Tests	Regression für API-/Auth-Layer
Frontend Build (docker compose exec frontend-dev npm run build)	Sicherstellen, dass keine Secrets im Bundle landen

Testfälle

1. Initiales Admin-Setup

1. curl -c cookies.txt http://localhost:5001/auth/setup/status → needsSetup prüfen.
2. Falls true: curl -X POST -H "Content-Type: application/json" -c cookies.txt -b cookies.txt \ -d '{"username":"admin","password":"SuperSicher123"}' \ http://localhost:5001/auth/setup/initial-admin → success: true, Cookie gesetzt.
3. curl -b cookies.txt http://localhost:5001/auth/setup/status → needsSetup:false, hasSession:true.
4. curl -b cookies.txt http://localhost:5001/auth/logout → 204, Cookie weg.

2. Login & CSRF (Backend-Sicht)

1. curl -X POST -H "Content-Type: application/json" -c cookies.txt -b cookies.txt \ -d '{"username":"admin","password":"SuperSicher123"}' http://localhost:5001/auth/login.
2. CSRF=$(curl -sb cookies.txt http://localhost:5001/auth/csrf-token | jq -r '.csrfToken').
3. curl -b cookies.txt -H "X-CSRF-Token: $CSRF" http://localhost:5001/api/admin/groups → 200.
4. Fehlerfälle prüfen:
   • Ohne Cookie → 403 { reason: 'SESSION_REQUIRED' }.
   • Mit Cookie aber ohne Token → 403 { reason: 'CSRF_INVALID' }.
   • Mit falschem Token → 403 { reason: 'CSRF_INVALID' }.

3. Moderations-UI (Frontend)

1. Browser auf http://localhost:3000/moderation → Login oder Setup-Wizard erscheint.
2. Wizard ausfüllen (nur beim ersten Start).
3. Normales Login durchführen (korrekte & falsche Credentials testen).
4. Nach Login folgende Aktionen validieren (Network-Tab kontrollieren: Requests senden Cookies + X-CSRF-Token):
   • Gruppenliste lädt.
   • Gruppe approve/reject.
   • Cleanup-Preview/-Trigger (falls Daten vorhanden).
   • Social-Media-Einstellungen laden/speichern.
5. Logout in der UI → Redirect zum Login, erneutes Laden zeigt Login.
6. Browser-Refresh nach Logout → kein Zugriff auf Admin-Daten (sollte Login anzeigen).

4. Regression Upload & Management

1. Normales Upload-Formular durchspielen (/): Gruppe hochladen.
2. Management-Link (/manage/:token) öffnen, Consents ändern, Bilder verwalten.
3. Sicherstellen, dass neue Session-Mechanik nichts davon beeinflusst.

5. Öffentliche APIs

1. curl http://localhost:5001/api/social-media/platforms → weiterhin öffentlich verfügbar.
2. Slideshow & Gruppenübersicht im Frontend testen (/slideshow, /groups).

6. Bundle-/Secret-Prüfung

1. Dev-Stack: docker compose -f docker/dev/docker-compose.yml exec frontend-dev npm run build (Prod analog mit docker/prod).
2. docker compose -f docker/dev/docker-compose.yml exec frontend-dev sh -c "grep -R 'ADMIN' build/" → keine geheimen Variablen (nur Dokumentationsstrings erlaubt).
3. Falls doch Treffer: Build abbrechen und Ursache analysieren.

7. Automatisierte Tests

1. Backend: docker compose -f docker/dev/docker-compose.yml exec backend-dev npm test (neue Auth-Tests müssen grün sein).
2. Optional: docker compose -f docker/dev/docker-compose.yml exec frontend-dev npm test oder vorhandene E2E-Suite per Container laufen lassen.

8. CI/Monitoring Checks

• Pipeline-Schritt hinzunehmen, der curl-Smoke-Test (Login + GET /api/admin/groups) fährt.
• Optionaler Script-Check, der das Frontend-Bundle auf Secrets scannt.

Testabschluss

• Alle oben genannten Schritte erfolgreich? → Feature gilt als verifiziert.
• Offene Findings dokumentieren in FeatureRequests/FEATURE_PLAN-security.md (Status + Follow-up).
• Nach Freigabe: Reviewer informieren, Deploy-Plan (z. B. neue Session-Secret-Verteilung) abstimmen.