Interne API-Sicherheitsrichtlinien

Sicherheitschecklisten, Perspektiven für die Codeüberprüfung und Richtlinienvorlagen für Entwicklungsteams.

📋 Checkliste für die Entwicklungsvorbereitung

Punkte, die vor der Entwicklung eines neuen API-Endpunkts zu überprüfen sind.

  • API-Spezifikation (OpenAPI) wurde erstellt
  • Die Authentifizierungs- und Autorisierungsmethoden wurden festgelegt
  • Eingabeparametertypen und -beschränkungen wurden definiert
  • Die Felder, die in den Antworten enthalten sein müssen, wurden klar definiert
  • Das Format der Fehlerantwort ist standardisiert
  • Es wurden Anforderungen zur Ratenbegrenzung festgelegt
  • Der Umgang mit personenbezogenen und sensiblen Daten wurde bestätigt
  • Die Authentifizierungsmethode wurde festgelegt (OAuth 2.0, JWT, API-Schlüssel)
  • Die erforderlichen Berechtigungen (Bereiche/Rollen) wurden für jeden Endpunkt definiert.
  • Es wurden Berechtigungsprüfungen auf Ressourcenebene entwickelt (BOLA-Gegenmaßnahme)
  • Verwaltungsfunktionen sind klar getrennt
  • Verfalls- und Aktualisierungsmethoden für Token wurden festgelegt
  • Die Kommunikation verwendet TLS 1.2 oder höher
  • Die Verschlüsselungsmethode für gespeicherte Daten wurde festgelegt
  • Maskierungs- und Anonymisierungsrichtlinien für persönliche Daten wurden festgelegt
  • Sensible Informationen (Token, Passwörter) sind nicht in den Protokollen enthalten
  • Debug-Informationen und Stack Traces sind nicht in API-Antworten enthalten

👀 Perspektiven der Codeüberprüfung

Sicherheitsperspektiven, die bei der Überprüfung des API-Codes zu prüfen sind.

Artikel prüfenBedeutungErläuterung
Authentifizierungs-Middleware wird auf alle Endpunkte angewendetErforderlichSicherstellen, dass außer bei öffentlichen APIs keine Authentifizierungsprüfungen fehlen
Berechtigungsprüfungen auf Objektebene existierenErforderlichÜberprüfen, ob die angeforderten Ressourcen dem anfragenden Benutzer gehören
Admin-Funktionen haben RollenüberprüfungErforderlichSicherstellen, dass normale Benutzer keine Admin-APIs aufrufen können
Algorithmus wird bei der JWT-Verifizierung angegebenErforderlichPrävention von alg: keine Angriffe
Der Token-Ablauf ist richtig konfiguriertEmpfohlenZugangstoken: innerhalb von 15 Minuten
Artikel prüfenBedeutungErläuterung
Anfragekörper hat SchemavalidierungErforderlichValidierung von Typ, Länge und Format
SQL-Abfragen sind parametrisiertErforderlichSicherstellen, dass Abfragen nicht mit String-Verkettung erstellt werden
Pfadparameter-Formatvalidierung vorhandenErforderlichPrüfung auf erwartetes Format wie UUID
Paginierungsparameter haben ObergrenzenEmpfohlenVerhindern Sie übermäßige Anfragen wie limit=999999
Datei-Uploads haben Beschränkungen in Bezug auf Typ und GrößeEmpfohlenValidierung von Content-Type und Dateigröße
Artikel prüfenBedeutungErläuterung
Die Antworten enthalten keine unnötigen FelderErforderlichVerhindern Sie die Preisgabe von password_hash, internen IDs usw.
Fehlerantworten enthalten keine Stack TracesErforderlichKeine internen Informationen in der Produktion preisgeben
Sicherheits-Header werden konfiguriertEmpfohlenX-Content-Type-Options, HSTS, usw.
Content-Type ist korrekt eingestelltEmpfohlenExplizite Angabe von application/json
Artikel prüfenBedeutungErläuterung
Ratenbegrenzung wird angewendetErforderlichInsbesondere für Authentifizierungs- und Zahlungsendpunkte
Entsprechende Protokolle werden aufgezeichnetEmpfohlenRückverfolgbar: Wer hat was wann getan?
Geheimnisse sind nicht fest kodiertErforderlichUmgebungsvariablen oder geheime Manager verwenden
CORS-Einstellungen sind angemessenEmpfohlenVermeiden Sie die Verwendung von Wildcards
Abhängigkeiten haben keine bekannten SchwachstellenEmpfohlenErgebnisse von npm audit / Snyk prüfen

📜 Vorlagen für Sicherheitsrichtlinien

Vorlagen für grundlegende Richtlinien für die interne API-Entwicklung. Anpassen an Ihr Projekt.

1. Authentifizierungspolitik

PolicyVorlage
■ Authentifizierungsmethoden
  - Benutzerseitige APIs: OAuth 2.0 (Autorisierungscode + PKCE)
  - Server-zu-Server-APIs: OAuth 2.0 (Client Credentials) oder mTLS
  - Externe Integrations-APIs: API-Schlüssel + HMAC-Signatur

■ Token-Verwaltung
  - Ablauf des Zugangstokens: 15 Minuten
  - Ablaufdatum des Refresh-Tokens: 7 Tage (Rotation erforderlich)
  - Token-Speicherung: HttpOnly + Sicher + SameSite Cookie

■ Passwort-Richtlinie
  - Mindestens 12 Zeichen, mindestens ein Großbuchstabe, ein Kleinbuchstabe, eine Zahl und ein Symbol
  - Hash mit bcrypt (Kostenfaktor 12 oder höher)
  - Passwortlisten-Angriffsschutz (Have I Been Pwned API-Integration)

2. API-Design-Politik

PolicyVorlage
■ Versionierung
  - Versionsverwaltung über URL-Pfad: /api/v1/resources
  - Mindestens 6-monatiger Supportzeitraum für alte Versionen
  - Meldung der Veralterung über Deprecation-Header

■ Ratenbegrenzung (Standardwerte)
  - Allgemeine APIs: 100 Anfragen/15 min
  - Auth-APIs: 5 Anfragen/15 min
  - Öffentliche APIs: 30 Anfragen/Min.
  - Immer RateLimit-*-Header zurückgeben

■ Antworten
  - Inhalts-Typ: application/json (fest)
  - Fehlerantworten im Format RFC 7807 (Problem Details)
  - In der Produktion werden niemals Stack Traces zurückgegeben
  - Paginierung: standardmäßig 20 Elemente, maximal 100 Elemente

3. Protokollierung und Audit-Politik

PolicyVorlage
■ Erforderliche Protokollfelder
  - Zeitstempel (ISO 8601, UTC)
  - Anfrage-ID (UUID für Rückverfolgbarkeit)
  - Benutzer-ID / API-Client-ID
  - HTTP-Methode + Endpunkt
  - Status Code
  - Quell-IP
  - Antwortzeit

■ Verbotene Log-Felder (Sensible Daten)
  - Kennwörter / Token / API-Schlüssel
  - Kreditkartennummern
  - Vollständige PII-Anzeige (Maskierung erforderlich)

■ Überwachungswarnungen
  - Authentifizierungsfehler: Warnung bei 5+/min
  - 403 Fehler: Warnung bei 10+/min
  - 500 Fehler: Sofortige Warnung bei 1 Auftreten
  - Ratengrenze überschritten: Musteranalyse

🚨 Ablauf der Reaktion auf Vorfälle

Phase 1: Aufdeckung

Erkennen von Vorfällen durch Überwachungswarnungen, Benutzerberichte oder externe Benachrichtigungen. Bestimmen Sie den Schweregrad durch eine erste Triage.

0-30 Minuten

Phase 2: Eindämmung

Verhindern Sie eine Eskalation des Schadens. Machen Sie API-Schlüssel ungültig, setzen Sie betroffene Endpunkte vorübergehend aus und ermitteln Sie den Umfang der Auswirkungen.

30 min - 2 Stunden

Phase 3: Ausrottung und Wiederherstellung

Behebung von Schwachstellen, Anwendung von Patches und Wiederherstellung von Diensten. Benachrichtigen Sie die betroffenen Benutzer.

2-24 Stunden

Phase 4: Analyse nach dem Vorfall

Postmortem durchführen. Durchführung einer Ursachenanalyse, Entwicklung von Maßnahmen zur Verhinderung eines erneuten Auftretens und Dokumentation der Ergebnisse.

1-5 Arbeitstage

🤖 AI / LLM Security Checklist

Additional checklist items for systems integrating AI models and LLM-powered features.

  • Model provider has been evaluated for security and compliance (SOC 2, data processing agreement)
  • System prompts are stored securely and not exposed to end users
  • Token budget and cost limits are configured per request and per user
  • Data classification policy defines what data can be sent to external LLM APIs
  • LLM outputs are validated and sanitized before rendering or downstream processing
  • Fallback behavior is defined for model unavailability or degraded responses
  • Model version pinning strategy is documented to prevent unexpected behavior changes
OWASP References

Related: LLM06: Excessive Agency, LLM02: Insecure Output Handling

  • Agent permissions follow least privilege principle — only necessary tools and APIs are accessible
  • Tool/function calling uses an explicit allowlist (not a denylist)
  • Human-in-the-loop approval is required for high-impact actions (payments, deletions, external communications)
  • Agent memory scope is bounded — conversation history does not leak across tenants or sessions
  • Inter-agent communication is authenticated and uses signed messages
  • Goal drift detection is implemented — agents are monitored for deviation from intended objectives
  • Emergency kill switch exists to halt agent execution immediately
OWASP References

Related: ASI01: Excessive Agency, ASI03: Insecure Tool/Function Calling, ASI09: Inadequate Sandboxing

  • Training data provenance is documented with lineage tracking
  • Data integrity checks exist for training and fine-tuning datasets (hash verification)
  • Model artifacts are versioned and stored in a tamper-proof registry
  • Model drift monitoring is in place to detect performance degradation
  • Third-party models and embeddings have been evaluated for known vulnerabilities
  • PII and sensitive data scrubbing is applied to training datasets
OWASP References

Related: LLM03: Training Data Poisoning, ML02: Data Poisoning Attack, ML06: AI Supply Chain Attacks

🧐 AI / LLM Code Review Perspectives

Security check items specific to code that integrates LLMs, AI agents, and ML models.

Artikel prüfenBedeutungErläuterung
System prompts are not exposed in client-side code or API responsesErforderlichPrompt leakage enables targeted prompt injection attacks
LLM outputs are validated before rendering (HTML/JS/SQL)ErforderlichLLM-generated content may contain XSS payloads or injection vectors
User input and system instructions are clearly separated in promptsErforderlichPrevents direct prompt injection by maintaining instruction-data boundary
Tool/function call permissions are scoped per user roleErforderlichPrevent privilege escalation through agent tool access
Token count limits are enforced per request and per sessionEmpfohlenPrevents cost explosion and denial-of-wallet attacks
RAG retrieval results are sanitized before insertion into promptsErforderlichRetrieved documents may contain indirect prompt injection payloads
Agent actions and tool calls are logged with full audit trailEmpfohlenEssential for incident investigation and compliance in AI systems

📑 AI / LLM Security Policy Templates

Policy templates for organizations deploying AI models and LLM-powered applications.

4. AI Model Access Control Policy

PolicyVorlage
■ Model Access Tiers
  - Tier 1 (Restricted): GPT-4 class / fine-tuned models — requires team lead approval
  - Tier 2 (Standard): GPT-3.5 class / embeddings — available to all developers
  - Tier 3 (Open): Open-source models (local inference) — no approval required

■ API Key Management for LLM Providers
  - One API key per service/environment (never share across projects)
  - Monthly spend alerts at 50%, 80%, 100% of budget
  - Hard spending caps enforced at the provider level
  - Key rotation: every 90 days or immediately upon team member departure

■ Data Sent to External Models
  - NEVER send: PII, credentials, internal IP, source code, customer data
  - ALLOWED with review: anonymized logs, public documentation, synthetic data
  - All prompts to external APIs must be logged (excluding PII)

5. AI Data Handling Policy

PolicyVorlage
■ Training Data Requirements
  - All training data must have documented provenance and licensing
  - PII must be removed or anonymized before use in training/fine-tuning
  - Data poisoning checks: validate data integrity with hash verification
  - Retain training data snapshots for reproducibility and audit

■ RAG (Retrieval-Augmented Generation) Data
  - Document ingestion pipeline must sanitize content (strip scripts, injections)
  - Access control on vector store must mirror source document permissions
  - Embedding models must be versioned and pinned

■ Model Output Data
  - LLM outputs must not be trusted as authoritative — always verify facts
  - Generated code must pass the same security review as human-written code
  - Outputs containing PII must be flagged and redacted before storage

6. AI Incident Classification Policy

PolicyVorlage
■ Severity Levels for AI-Specific Incidents
  - P1 (Critical): Prompt injection leading to data exfiltration or unauthorized actions
  - P1 (Critical): Model serving compromised or returning manipulated outputs
  - P2 (High): Training data poisoning detected, jailbreak bypass discovered
  - P2 (High): Agent performing unintended actions outside approved scope
  - P3 (Medium): Model drift causing degraded accuracy below threshold
  - P4 (Low): Cost overrun due to excessive token usage

■ Response Procedures
  - P1: Immediately disable affected model endpoint, notify security team
  - P2: Quarantine affected model version, roll back to last known good
  - P3: Trigger retraining pipeline, increase monitoring frequency
  - P4: Adjust rate limits and budget caps, review usage patterns

■ Post-Incident Requirements
  - Root cause analysis within 48 hours for P1/P2
  - Update prompt injection test suite with new attack vectors
  - Review and update guardrails configuration

⚡ Kurzübersicht: HTTP Status Codes

Sicherheitsrelevante HTTP-Statuscodes, die beim API-Design verwendet werden.

CodeBedeutungAnwendungsfall
400Bad RequestFehler bei der Eingabeüberprüfung
401UnauthorizedAuthentifizierung erforderlich oder Token ist ungültig
403ForbiddenAuthentifiziert, aber unzureichende Berechtigungen
404Not FoundRessource existiert nicht (kann auch anstelle von 403 verwendet werden)
405Method Not AllowedHTTP-Methode nicht erlaubt
413Payload Too LargeAnfragekörpergröße überschritten
422Unprocessable EntityDie Syntax ist korrekt, aber die Semantik fehlerhaft
429Too Many RequestsRatengrenze überschritten
500Internal Server ErrorInterner Serverfehler (Details ausblenden)