Seminar NestJS – API-Sicherheit mit Authentifizierung und Autorisierung

Produktionsreife APIs benötigen ein konsistentes Sicherheitsmodell, das Identität, Berechtigungen, Eingaben, Fehlerausgaben und Betriebsdaten gemeinsam betrachtet. Einzelne Guards oder ein signiertes Token reichen nicht aus, wenn Vertrauensgrenzen, Token-Lebenszyklen und Missbrauchsszenarien ungeklärt bleiben.

Der Kurs entwickelt ein vollständiges Schutzkonzept an einer modularen Beispielanwendung. Jede Maßnahme wird fachlich begründet, implementiert und mit positiven sowie negativen Tests abgesichert. Dadurch entsteht ein wiederverwendbarer Entscheidungsrahmen für interne APIs, Partner-Schnittstellen und öffentlich erreichbare Dienste.

Inhaltsübersicht

• Lernziele
• Bedrohungsmodell und Vertrauensgrenzen
• Authentifizierung und Token-Lebenszyklus
• Autorisierung mit Rollen und Policies
• API-Härtung und sichere Verarbeitung
• Automatisierte Sicherheitsprüfung
• Praxisprojekt: Geschützte Mandanten-API
• Prüfpunkte und typische Fehler

Lernziele

• Vertrauensgrenzen, schützenswerte Ressourcen und Angriffsflächen einer NestJS-Anwendung strukturiert erfassen.
• Authentifizierungsflüsse mit kurzlebigen Zugriffstoken und kontrollierter Erneuerung umsetzen.
• Rollenbasierte und attributbasierte Berechtigungsentscheidungen mit Guards, Metadaten und Policies modellieren.
• Eingaben, Fehlerausgaben, Header, CORS, Uploads und Request-Raten sicher konfigurieren.
• Secrets, Schlüsselmaterial und sicherheitsrelevante Konfigurationen getrennt vom Anwendungscode verwalten.
• Sicherheitsfunktionen mit Unit-, Integrations- und End-to-End-Tests reproduzierbar prüfen.

Bedrohungsmodell und Vertrauensgrenzen

Die Anwendung wird nach Schutzbedarf und Datenflüssen zerlegt. Externe Clients, interne Dienste, Datenbanken, Nachrichtenkanäle und Administrationsfunktionen erhalten klar definierte Vertrauensniveaus.

1. Assets, Identitäten, Mandanten, Rollen und besonders schützenswerte Operationen inventarisieren.
2. Angriffswege für gestohlene Token, manipulierte Eingaben, Rechteausweitung und automatisierten Missbrauch beschreiben.
3. Sicherheitsentscheidungen an der fachlichen Ressource statt nur an der URL ausrichten.
4. Fehlerfälle so planen, dass keine internen Details, Abfragen oder Stacktraces offengelegt werden.
5. Protokollierungsbedarf und Datenschutz bereits im Sicherheitsentwurf berücksichtigen.

Entscheidungskriterien und Hinweise

• Bedrohungsmodelle bleiben versioniert und werden bei neuen Integrationen aktualisiert.
• Schutzmaßnahmen werden nach Risiko und nicht nach bloßer technischer Verfügbarkeit priorisiert.

Authentifizierung und Token-Lebenszyklus

Die Identitätsprüfung wird als austauschbare Schicht aufgebaut. Lokale Zugangsdaten, zentrale Identitätsanbieter und servicebasierte Identitäten lassen sich dadurch trennen, ohne die Fachlogik an ein einzelnes Verfahren zu koppeln.

1. Benutzer- und Credential-Modell mit eindeutigen Zuständen für aktiv, gesperrt und zurückgesetzt definieren.
2. Login-DTO validieren, Fehlermeldungen vereinheitlichen und rechenintensive Prüfungen begrenzen.
3. Zugriffstoken mit minimalen Claims, kurzer Gültigkeit sowie Aussteller- und Zielgruppenbindung ausstellen.
4. Erneuerungstoken getrennt speichern, rotieren, widerrufen und Wiederverwendung erkennen.
5. Guards für öffentliche, authentifizierte und besonders geschützte Routen kombinierbar gestalten.
6. Abmeldung, Sperrung, Schlüsselrotation und kompromittierte Sitzungen als Betriebsfälle testen.

Entscheidungskriterien und Hinweise

• Token dienen als Nachweis und nicht als dauerhafte Datenablage.
• Schlüsselrotation benötigt eine kontrollierte Übergangsphase mit mehreren gültigen Schlüsseln.

Autorisierung mit Rollen und Policies

Eine authentifizierte Identität besitzt nicht automatisch Zugriff auf jede fachliche Ressource. Rolle, Besitz, Mandant, Objektstatus und konkrete Aktion werden in einer einheitlichen Entscheidung zusammengeführt.

1. Rollen als grobe Funktionszuordnung definieren und zentral über Metadaten auswerten.
2. Aktion, Ressource, Identität und Kontext in ein Policy-Entscheidungsobjekt überführen.
3. Eigentum, Mandantenzugehörigkeit, Freigabestatus und zeitliche Einschränkungen berücksichtigen.
4. Berechtigungsentscheidungen aus Controllern und Services in wiederverwendbare Komponenten verlagern.
5. Vererbte Rollen und kombinierte Policies mit erlaubten und verweigerten Szenarien testen.
6. Entscheidungsgründe protokollierbar machen, ohne sensible Daten in Logs zu schreiben.

Entscheidungskriterien und Hinweise

• Rollen ersetzen keine objektbezogenen Fachregeln.
• Verweigerte Zugriffe dürfen keine Daten oder Seiteneffekte erzeugen.

API-Härtung und sichere Verarbeitung

Validierung, Transformation, Header, Cross-Origin-Regeln und Begrenzungen werden zentral eingerichtet, damit neue Module automatisch einem sicheren Standard folgen.

1. Globale ValidationPipe mit Whitelist, Transformation und kontrolliertem Verhalten bei unbekannten Feldern konfigurieren.
2. Mass Assignment durch getrennte Eingabe- und Ausgabemodelle verhindern.
3. Sicherheitsheader, CORS-Regeln und Proxy-Vertrauen passend zur Zielarchitektur einstellen.
4. Rate Limiting differenziert für Anmeldung, Lesezugriffe und teure Schreiboperationen einsetzen.
5. Dateiuploads nach Größe, Typ, Inhalt, Speicherort und Berechtigung begrenzen.
6. Serialisierung und Exception Filter so konfigurieren, dass interne Felder verborgen bleiben.
7. Secrets und Schlüsselmaterial ausschließlich über kontrollierte Konfigurationsquellen laden.

Entscheidungskriterien und Hinweise

• CORS ist keine Autorisierung und schützt keine serverseitigen Clients.
• Proxy-Vertrauen beeinflusst IP-basierte Kontrollen und muss der realen Topologie entsprechen.

Automatisierte Sicherheitsprüfung

Sicherheitsanforderungen werden als ausführbare Regeln behandelt. Negative Tests prüfen Statuscode, Datenabfluss, Seiteneffekte und sensible Fehlermeldungen.

1. Testmatrix aus Identitäten, Rollen, Mandanten, Ressourcenstatus und Aktionen ableiten.
2. Guards und Policy-Handler mit isolierten Unit-Tests prüfen.
3. Login, Token-Erneuerung, Sperrung und Widerruf in Integrationstests abbilden.
4. End-to-End-Tests für fehlende, manipulierte, abgelaufene und wiederverwendete Token erstellen.
5. Validierungs-, Rate-Limit- und Fehlerausgabe-Szenarien automatisiert prüfen.
6. Sicherheitsrelevante Tests als Release-Gates in die Pipeline aufnehmen.

Entscheidungskriterien und Hinweise

• Positive Tests belegen Funktion, negative Tests belegen Schutzwirkung.
• Logs und Audit-Ereignisse werden ebenfalls auf unerlaubte Dateninhalte geprüft.

Praxisprojekt: Geschützte Mandanten-API

Eine bestehende REST-API wird um Anmeldung, Token-Rotation, Mandantentrennung und fachliche Berechtigungen erweitert. Die Anwendung enthält öffentliche, authentifizierte und administrative Operationen sowie einen besonders geschützten Export.

Der Prüfpfad kombiniert Funktions- und Missbrauchsszenarien. Erlaubte Operationen müssen funktionieren; unerlaubte Zugriffe dürfen weder Daten liefern noch Seiteneffekte erzeugen.

1. Schutzbedarf, Rollen, Mandantenregeln und sensible Operationen in einer Sicherheitsmatrix dokumentieren.
2. Authentifizierungsmodul mit Zugriffstoken, Erneuerung, Rotation und Widerruf implementieren.
3. Rollen- und Policy-Guards für Objektzugriffe, Export und Administration ergänzen.
4. Globale Validierung, Fehlerfilter, Sicherheitsheader und differenziertes Rate Limiting aktivieren.
5. Secrets und Schlüssel über die Konfiguration einbinden und einen Rotationsfall simulieren.
6. Negative End-to-End-Tests für Rechteausweitung, Mandantenwechsel und manipulierte Token erstellen.
7. Audit-Ereignisse prüfen und sicherstellen, dass keine Zugangsdaten oder vollständigen Token protokolliert werden.

Prüfpunkte und typische Fehler

• Authentifizierung und Autorisierung werden getrennt bewertet.
• Berechtigungsregeln befinden sich nicht als verstreute Bedingungen in Controllern oder Services.
• Token enthalten nur notwendige Claims und besitzen einen kontrollierten Lebenszyklus.
• Fehlermeldungen verraten keine unnötigen Details über Konten, Datenmodell oder Infrastruktur.
• Proxy-, CORS- und Rate-Limit-Konfiguration entsprechen der tatsächlichen Bereitstellungsarchitektur.
• Negative Tests prüfen auch Datenabfluss, Seiteneffekte und Log-Inhalte.