Claude Code Sicherheits-Checkliste für schnelle Spot-Checks von Web-Apps

Was ein leichter Sicherheits-Spot-Check ist

Ein leichter Sicherheits-Spot-Check ist eine schnelle Prüfung (oft 30–60 Minuten), die offensichtliche, hochrelevante Probleme finden soll, bevor etwas ausgeliefert wird. Es ist kein vollständiges Audit. Denk daran wie an einen Sicherheitsrundgang: Du scannst die Pfade, an denen in echten Apps am häufigsten etwas schiefgeht, und suchst nach Beweisen, nicht nach Vermutungen.

Diese Claude Code Sicherheits-Checkliste konzentriert sich auf die Bereiche, die in alltäglichen Web-Apps am häufigsten versagen:

• Annahmen zur Authentifizierung (wie du weißt, wer der Nutzer ist)
• Lücken in der Autorisierung (was erlaubt ist)
• Validierung von Eingaben
• Umgang mit Geheimnissen
• Häufige Injection-Oberflächen (SQL, Kommandoausführung, Template-Rendering, Redirects, Uploads)

Sie versucht nicht, das Fehlen von Bugs zu beweisen, komplexe Angreifermodelle zu modellieren oder Penetrationstests zu ersetzen.

„Konkrete Befunde" bedeutet, dass jedes Problem, das du dokumentierst, Belege enthält, mit denen ein Entwickler sofort arbeiten kann. Für jeden Befund erfasse:

• Die genaue Datei(en) und den Funktions-/Handler-Namen
• Das riskante Verhalten in einem Satz
• Einen minimalen Reproduktionsschritt (Request, Payload oder Klickpfad)
• Warum es wichtig ist (Impact) und wer es auslösen kann
• Eine sichere Richtung für die Behebung (kein kompletter Rewrite)

KI ist Helfer, nicht Autorität. Nutze sie zum Suchen, Zusammenfassen und Vorschlagen von Tests. Verifiziere dann durch Lesen des Codes und, wenn möglich, durch Reproduktion mit einer echten Anfrage. Wenn das Modell keine spezifischen Orte und Schritte nennen kann, behandle die Aussage als unbelegt.

Scope in 10 Minuten festlegen

Eine schnelle Prüfung funktioniert nur, wenn du das Ziel eingrenzt. Bevor du Claude Code etwas anschauen lässt, entscheide, was du heute beweisen willst und was nicht geprüft wird.

Beginne mit 1 bis 3 echten Nutzer-Journeys, bei denen Fehler Geld kosten, Daten offenlegen oder Macht gewähren. Gute Kandidaten sind Login, Passwort-Reset, Checkout und Admin-Edit-Screens.

Nenne als Nächstes die Assets, die du schützen musst. Sei spezifisch: Nutzerkonten, Zahlungsaktionen, personenbezogene Daten, admin-only Operationen.

Schreibe dann deine Bedrohungsannahmen in einfachen Worten auf. Verteidigst du gegen einen neugierigen Nutzer, der rumklickt, einen externen Angreifer mit Scripts oder einen Insider mit Teilzugang? Deine Antwort ändert, was „gut genug" bedeutet.

Definiere schließlich Pass/Fail, damit dein Spot-Check mit Befunden endet, nicht mit Gefühlen. Einfache Regeln funktionieren gut:

• Pass: Jede sensitive Aktion zeigt einen expliziten Authn- und Authz-Check.
• Fail: Ein Endpoint vertraut dem Client für User-ID oder Rolle.
• Pass: Eingaben werden serverseitig validiert, nicht nur in der UI.
• Fail: Geheimnisse erscheinen in Logs, Konfigurationen oder Client-Code.

Wenn du nicht beschreiben kannst, wie ein Fehlschlag aussieht, ist der Scope noch zu unscharf.

Kontext, den du Claude Code bereitstellst

Ein Spot-Check funktioniert nur, wenn das Modell die richtigen Stellen betrachtet. Sammle ein kleines Paket aus Code und Notizen, damit die Prüfung Beweise liefern kann, keine Vermutungen.

Beginne damit, den sicherheitskritischen Pfad zu teilen: Entry-Points von Requests und der Code, der entscheidet, wer der Nutzer ist und was er darf. Füge gerade genug umgebenden Code hinzu, um den Datenfluss zu zeigen.

Ein praktisches Paket enthält gewöhnlich:

• Auth-Entry: Session-/JWT-Parsing, Cookie-Einstellungen, Login-Callbacks, Auth-Middleware
• Routes + Handler: Controller, RPC-Methoden, GraphQL-Resolver, Background-Job-Handler
• Daten-Schicht: ORM-Queries, Raw-SQL-Helper, Query-Builder, Migrationen für sensitive Tabellen
• Policy-Checks: Rollenprüfungen, Ownership-Checks, Feature-Flags, Admin-only Endpoints
• Validierung: Request-Schema-Validatoren, File-Upload-Handler, Deserialisierungs-Code

Füge ein paar Zeilen zu Umgebungsannahmen hinzu: Session vs. JWT, wo Tokens leben (Cookie oder Header), Reverse Proxy oder API-Gateway-Verhalten, Queues/Cron-Worker und alle „internal-only" Endpoints.

Bevor du Bugs jagst, frage nach einem Inventar: Entry-Points, privilegierte Endpoints und betroffene Datenspeicher. Das verhindert übersehene Oberflächen.

Stimme auch ein Ausgabeformat ab, das zu konkreten Befunden zwingt. Eine einfache Tabelle funktioniert gut: Finding, Severity, Betroffener Endpoint/Datei, Evidence (genauer Ausschnitt oder Zeilenbereich), Exploit-Szenario, Fix-Vorschlag.

Schritt-für-Schritt-Workflow für eine 30–60 Minuten-Prüfung

Zeitboxe es:

• 10 Minuten zur Orientierung
• 15–30 Minuten, um Flows zu verfolgen
• 10 Minuten, um aufzuschreiben

Ziel ist keine perfekte Abdeckung. Es geht um eine kleine Menge testbarer Befunde.

Habe die App offen, während du liest. Klick dich durch die UI und beobachte, welche Requests ausgelöst werden. Notizen sollten auf spezifische Endpoints, Parameter und Datenquellen verweisen.

Ein Workflow, der in einer Sitzung passt:

1. Skizziere Entry-Points und Vertrauensgrenzen. Notiere öffentliche Routen, eingeloggte Routen, Admin-Routen, Webhooks, Uploads und Third-Party-Callbacks. Markiere, wo Daten vom Nutzerkontrollierten in server-trusted übergehen.
2. Für jeden wichtigen Endpoint schreibe auf, was Identität beweist und wo das passiert. Wenn der Check "Middleware" ist, verifiziere, dass jede Route sie tatsächlich nutzt.
3. Das Gleiche für Autorisierung: Wähle eine riskante Aktion (andere Nutzer sehen, Rollen ändern, exportieren, löschen) und verfolge die Berechtigungsentscheidung bis zur Datenbank-Query.
4. Verfolge Benutzereingaben zu Sinks. Folge einem Parameter von Request bis zu SQL/ORM-Queries, Template-Rendering, Kommandoausführung, URL-Fetches (SSRF), Redirects und Dateipfaden.
5. Scanne Geheimnisse und Konfigurationen, während du verfolgst. Suche nach Tokens in Logs, Client-Code, Fehlermeldungen und Environment-Dumps.

Eine nützliche Gewohnheit: Für jedes "scheint in Ordnung" schreibe, wie du es kaputtprüfen würdest. Wenn du keinen Bruchversuch beschreiben kannst, hast du es wahrscheinlich nicht verifiziert.

Authn-Spot-Checks: Beweise, wer der Nutzer ist

Authentifizierung ist der Punkt, an dem die App entscheidet: „Diese Anfrage gehört zu dieser Person." Ein schneller Spot-Check geht nicht jede Zeile durch. Er findet die Stelle, an der Identität hergestellt oder akzeptiert wird, und prüft Abkürzungen und Fehlerpfade.

Finde die Vertrauensgrenze: Wo wird Identität zuerst erstellt oder akzeptiert? Das kann ein Session-Cookie, ein JWT-Bearer-Token, ein API-Key oder mTLS am Edge sein. Bitte Claude Code, die genaue Datei und Funktion zu nennen, die "anonymous" in eine User-ID verwandelt, und alle anderen Pfade, die das ebenfalls tun können.

Authn-Checks, die sich lohnen zu scannen:

• Identifiziere alle Auth-Entry-Points (Web-Login, API-Tokens, Mobile-Auth, interne Service-Auth) und bestätige, dass sie auf ein konsistentes Identitätsmodell zusammenlaufen.
• Prüfe Login und Passwort-Reset auf Rate-Limits, Sperrmechanismen und User-Enumeration (unterschiedliche Fehlermeldungen oder Timing für existierende vs. nicht-existierende Accounts).
• Inspect Session und Cookies: HttpOnly, Secure, SameSite, Ablauf, Rotation beim Login und Privilege-Change, und Logout-Invaliderung (serverseitig, nicht nur "Cookie löschen").
• Prüfe MFA und Recovery, sodass der Recovery-Pfad nicht schwächer ist als MFA (z. B. E-Mail-only Reset, der MFA umgeht).
• Prüfe Auth-Failure-Logging: Nützlich für Ops, aber darf keine Details offenlegen, die Angreifern helfen (kein "User exists"-Hinweis, keine Token-Dumps).

Ein praktisches Beispiel: Wenn Reset-Mails "Account nicht gefunden" zurückgeben, ist das ein schnelles Enumeration-Problem. Auch mit generischer Meldung können Timing-Unterschiede dieselbe Info leaken, also prüfe Antwortzeiten.

Authz-Spot-Checks: Beweise, dass der Nutzer darf

Autorisierung verursacht den meisten Schaden, wenn sie falsch ist: "Darf dieser Nutzer diese Aktion auf genau dieser Ressource durchführen?" Ein schneller Spot-Check sollte diese Annahme absichtlich zu brechen versuchen.

Formuliere Rollen und Berechtigungen in plainer Sprache. Halte es menschlich:

• Owner kann Mitglieder einladen
• Member kann sein eigenes Profil bearbeiten
• Support kann Rechnungsdaten ansehen, aber den Plan nicht ändern
• Admin kann Projekte löschen

Verifiziere dann, dass jede sensitive Aktion die Autorisierung serverseitig durchsetzt, nicht nur in der UI. Buttons können verborgen werden, Routen im Client blockiert sein — ein Angreifer kann trotzdem direkt die API aufrufen.

Ein Scan, der oft echte Probleme findet:

• Finde Endpoints/Mutations, die erstellen, löschen, exportieren, Rollen ändern oder Billing-Zugriff bieten
• Für jeden Endpoint: finde die serverseitige Permission-Check (nicht das Frontend)
• Suche nach nutzer-kontrollierten IDs (projectId, userId, orgId) und bestätige Ownership-Checks
• Bestätige, dass Admin-only Pfade closed-failen, wenn die Rolle fehlt
• Prüfe Mandanten-Grenzen: orgId/accountId sollte aus dem Session-Kontext kommen, nicht nur aus der Anfrage

Der klassische IDOR-Geruch ist simpel: eine Anfrage wie GET /projects/{id}, wobei {id} kontrolliert ist und der Server es lädt, ohne zu prüfen, ob es zum aktuellen Nutzer oder Tenant gehört.

Ein Prompt, der eine echte Antwort erzwingt:

"Für diesen Endpoint zeig den exakten Code, der den Zugriff entscheidet, und liste die konkreten Bedingungen auf, die es einem Nutzer einer anderen orgId erlauben würden, darauf zuzugreifen. Wenn keine, erkläre warum mit Datei- und Funktionsnamen."

Input-Validierung: Schlechtes schnell draußen halten

Die meisten schnellen Web-App-Probleme beginnen mit einer Lücke: Die App akzeptiert Eingaben, die der Entwickler nicht erwartet hat. Betrachte "Input" als alles, was ein Nutzer oder ein anderes System beeinflussen kann, auch wenn es harmlos erscheint.

Beginne damit, die Eingaben für den Endpoint zu benennen, den du prüfst:

• URL-Query- und Path-Werte
• Request-Body-Felder (auch verschachteltes JSON)
• Header (Auth-Header, Content-Type, Forwarded-IP)
• Cookies
• File-Uploads (Name, Größe, Typ, Metadaten)

Validierung sollte nahe der Stelle passieren, an der Daten in die App treten, nicht tief in der Business-Logik. Prüfe die Basics: Typ (String vs. Number), Maximallänge, Pflicht vs. optional und Format (E-Mail, UUID, Datum).

Für bekannte Werte wie Rollen, Status-Felder oder Sortierrichtungen bevorzuge eine Allowlist. Das ist schwerer zu umgehen als "ein paar böse Werte blockieren".

Prüfe auch das Fehlerhandling. Wenn die App Eingaben ablehnt, echo nicht den rohen Wert in der Antwort, in Logs oder der UI. So werden kleine Validierungsfehler zu Datenlecks oder Injection-Hilfen.

Ein kurzer "Bad Input" Mini-Plan für riskante Endpoints (Login, Search, Upload, Admin-Aktionen):

• Überlange Strings (10.000+ Zeichen)
• Falsche Typen (Array statt String)
• Unerwartete Enum-Werte
• Sonderzeichen, die Bedeutung ändern können
• Leere Werte für Pflichtfelder

Beispiel: Ein Sort-Parameter, der beliebige Strings akzeptiert, kann später zu einem SQL-Fragment werden. Eine Allowlist wie "date" oder "price" verhindert diese Fehlerklasse früh.

Häufige Injection-Oberflächen, die du schnell scannst

Die meisten schnellen Reviews finden Probleme an denselben wenigen Stellen: überall dort, wo Nutzereingabe als Code, Query, Pfad oder URL interpretiert wird. Hier suchst du nach Momenten, in denen "Input eine Vertrauensgrenze überquert".

Verfolge Daten von Entry-Points (Query-Params, Header, Cookies, Uploads, Admin-Formulare) bis zu ihren Zielorten.

Schnell-Scan-Ziele

Achte auf diese Muster und verlange für jedes einen konkreten Call-Site- und Payload-Beispiel:

• SQL-Injection: string-basierte Queries, dynamisches ORDER BY, und IN (...)-Builder, die Werte zusammenfügen
• XSS: HTML-Rendering, Templates, Markdown-Previews, Rich-Text-Editoren, bei denen "später säubern" angenommen wird
• Command-Injection: Shell-Aufrufe z. B. bei Bildverarbeitung, PDF-Tools, Backups oder "convert"-Schritten, die user-kontrollierte Flags übergeben
• SSRF: URL-Fetcher für Webhooks, Link-Previews, Import-from-URL-Features und interne Status-Checks, die eine Nutzer-URL akzeptieren
• Path-Traversal: File-Download-Endpunkte, Zip-Extraktion, Upload-Pipelines, die später Dateien nach Name lesen

Achte auch auf Deserialisierung und Template-Injection. Alles, was nutzer-providiertes JSON, YAML oder template-basierte Strings parst, kann riskantes Verhalten verbergen, besonders bei Unterstützung für benutzerdefinierte Typen, Ausdrücke oder serverseitiges Rendering.

Wenn ein Feature eine URL, einen Dateinamen oder formatierten Text akzeptiert, gehe davon aus, dass es missbraucht werden kann, bis du den Codepfad und Tests geprüft hast.

Geheimnisverwaltung: Lecks und schwaches Speichern finden

Probleme mit Geheimnissen sind oft laut, sobald du weißt, wo du suchen musst. Konzentriere dich darauf, wo Geheimnisse leben und wo sie versehentlich kopiert werden.

Häufige Orte, an denen Geheimnisse auftauchen:

• Environment-Variablen und App-Konfigurationsdateien
• CI-Ausgaben und Build-Logs (inklusive fehlgeschlagener Deploy-Logs)
• Client-Bundles und Mobile-Builds (alles, was an Nutzer ausgeliefert wird)
• Debug-Endpoints, Health-Pages und Admin-Tools
• Fehlerseiten, Stacktraces und Analytics-Events

Fordere dann eine konkrete Antwort: Wenn ein Geheimnis heute exponiert ist, was passiert als Nächstes? Ein gutes System hat einen Rotationspfad (neuer Key), Widerruf (alter Key deaktiviert) und schnellen Redeploy. Wenn die Antwort "wir würden es später ändern" lautet, behandle das als Befund.

Least-Privilege ist ein weiterer schneller Gewinn. Vorfälle werden schlimmer, weil Keys zu mächtig sind. Suche nach DB-Usern, die Tabellen droppen können, Third-Party-Tokens, die Konten verwalten, oder API-Keys, die über Umgebungen geteilt werden. Bevorzuge einen Key pro Service, pro Umgebung, mit minimalen Rechten.

Kurze Spot-Check-Prompts, die du in Claude Code einfügen kannst:

• "Search for hard-coded tokens, passwords, and private keys. List exact file paths and the string patterns you matched." (Suche nach hartkodierten Tokens, Passwörtern und privaten Schlüsseln. Nenne genaue Dateipfade und die String-Muster.)
• "Find any code that logs request headers, cookies, env vars, or full error objects. Show the log lines and what sensitive fields could appear." (Finde Code, der Request-Header, Cookies, Env-Vars oder ganze Error-Objekte loggt. Zeige Log-Zeilen und welche sensitiven Felder erscheinen könnten.)
• "Check if secrets can end up in snapshots, exports, or build artifacts. Identify what gets captured and where it is stored." (Prüfe, ob Geheimnisse in Snapshots, Exports oder Build-Artefakten landen. Identifiziere, was erfasst wird und wo es gespeichert ist.)

Bestätige schließlich Guardrails: blockiere Geheimnisse im Source Control (Pre-Commit/CI-Checks) und stelle sicher, dass Backups oder Snapshots keine Klartext-Zugangsdaten enthalten. Wenn deine Plattform Snapshots und Rollbacks unterstützt, verifiziere, dass Geheimnisse zur Laufzeit injiziert werden, nicht in gespeicherte Images gebacken sind.

Prompts, die konkrete Befunde erzwingen (Copy-Paste-Muster)

Vage Prompts liefern vage Antworten. Zwinge das Modell, sich zu Belegen zu verpflichten: exakte Orte, einen Trace, eine Repro, und was die Behauptung widerlegen würde.

Nutze jeweils ein Muster und lass es nach Bestätigung oder Ablehnung überarbeiten.

• Dateiebene-Evidence: "Search the repo for auth, sessions, tokens, and middleware. Name the exact files, functions, and line ranges involved. Quote the relevant snippets. If you cannot point to code, say 'no evidence found'."
• Trace von Input zu Sink: "Pick one user-controlled input (header, query, body, cookie). Show the data flow step-by-step from entry point to where it is used (SQL, HTML, shell, template, redirect, file path). List each function in the chain."
• Repro-Schritte: "Give a minimal repro with curl (method, URL shape, headers, body). Include expected status code and a success/failure response example. State assumptions (roles, auth state)."
• False-Positive-Kontrolle: "What would disprove this finding? List 2-3 checks: config flags, middleware order, allowlist validation, parameterized queries, framework escaping. If any are present, explain why risk changes."
• Kleinste sichere Behebung + Test: "Propose the smallest change that blocks the issue without breaking valid cases. Then write one test to add (name, intent, inputs, expected result). If there are tradeoffs, spell them out."

Wenn die Ausgabe noch unscharf ist, pinne sie fest:

"Answer only with: file path, function name, risky line, and one-sentence impact."

Ein realistisches Beispiel: Eine Vermutung in ein verifiziertes Problem verwandeln

Profile-Update-Endpoints verbergen oft Access-Control-Bugs. Hier ein kleiner Fall, den du durch die Checkliste laufen lassen kannst.

Scenario: Ein API-Endpoint aktualisiert ein Nutzerprofil:

PATCH /api/profile?accountId=123 mit JSON wie { "displayName": "Sam" }.

Du bittest Claude Code, den Handler zu finden, nachzuverfolgen, wie accountId verwendet wird, und zu beweisen, ob der Server Ownership durchsetzt.

Was häufig auftaucht:

• Authn: Die Anfrage benötigt eine Session oder ein Token, wirkt also geschützt.
• Authz: Der Handler vertraut accountId aus dem Query-String und updated dieses Konto, ohne zu prüfen, ob es zum eingeloggten Nutzer gehört.
• Input-Validierung: displayName wird getrimmt, aber accountId nicht als Integer validiert.
• Injection-Oberfläche: SQL wird per String-Konkatenation gebaut wie "... WHERE account_id=" + accountId.

Eine gute Zusammenfassung ist konkret:

• Severity: High (IDOR + mögliche SQL-Injection)
• Evidence: Eine Anfrage mit gültigem Login ändert ein anderes Konto, wenn accountId modifiziert wird; SQL wird aus untrusted Input gebaut
• Fix: Ignoriere accountId vom Client, nutze die authentifizierte Account-ID serverseitig; parameterisiere die Query
• Test: Versuch, ein anderes Konto zu updaten und erwarte 403; lehne nicht-numerische accountId ab

Nach dem Patch schnell erneut prüfen:

• Versuche dieselbe Anfrage mit einer anderen accountId und bestätige, dass sie fehlschlägt.
• Bestätige, dass Logs zeigen, dass der Server die authentifizierte ID nutzt, nicht den Query-Param.
• Bestätige, dass die Query Platzhalter/Parameter verwendet, nicht String-Building.
• Führe einen Negativtest für malformed Input (Buchstaben, sehr große Zahl) aus.

Häufige Fallen, die Spot-Checks echte Probleme übersehen lassen

Der schnellste Weg, eine Vulnerability zu übersehen, ist, dem zu vertrauen, was die UI durchzusetzen scheint. Ein Button, der verborgen oder deaktiviert ist, ist keine Berechtigungsprüfung. Wenn der Server die Anfrage trotzdem annimmt, kann jeder sie mit einer anderen User-ID, Rolle oder direktem API-Call wiederholen.

Eine weitere häufige Lücke ist eine vage Anfrage. "Mach ein Security-Review" liefert meist einen generischen Report. Ein Spot-Check braucht einen engen Scope (welche Endpoints, welche Rollen, welche Daten) und ein striktes Ausgabeformat (Dateiname, Funktion, riskante Zeile, minimaler Repro).

Dasselbe gilt für KI-Ausgaben: Akzeptiere keine Behauptungen ohne Verweise. Wenn ein Befund keinen konkreten Code-Ort und keinen Schritt-für-Schritt-Trigger enthält, behandle ihn als unbelegt.

Schnelle Wege, wie Spot-Checks falsch laufen

Diese Fallen treten immer wieder auf:

• Annahme von "admin-only", weil es eine Admin-Seite ist, statt weil der Server es durchsetzt
• Breite Review-Ergebnisse anfordern statt: "Zeig mir die genaue Anfrage, die X umgeht"
• "Mögliche SQL-Injection" akzeptieren ohne die Query-Konstruktionsstelle und Input-Pfade
• Ungewöhnliche Entry-Points wie Webhooks, Scheduled Jobs, Import-Tools und interne Admin-Aktionen überspringen
• Symptome patchen (Filter oder Regex hinzufügen), während die Root-Cause-Validierung oder Autorisierung fehlt

Wenn du dich erwischst, nach jedem neuen Edge-Case noch einen Filter hinzuzufügen, stoppe. Die Lösung ist meist einfacher und früher: validiere Eingaben an der Grenze und mache Autorisierung explizit und zentral, sodass jeder Codepfad sie nutzt.

Schnelle Checks, die du vor dem Release durchführen kannst

Diese ersetzen kein vollständiges Review, fangen aber Fehler, die einschleichen, wenn alle müde sind. Halte sie auf das fokussiert, was du schnell beweisen kannst: eine Anfrage, die du senden kannst, eine Seite, die du laden kannst, eine Log-Zeile, die du finden kannst.

Fünf schnelle Spot-Checks, die sich meist auszahlen:

• Authn-Friction: Versuche 10 fehlerhafte Logins hintereinander. Siehst du Rate-Limits, Sperrungen oder zumindest Verlangsamung? Kannst du aus Fehlermeldungen oder Timing erkennen, ob eine E-Mail existiert?
• Authz per ID-Swap: Wähle eine echte Ressource (Order, Invoice, Profile). Ändere die ID in URL, JSON-Body oder GraphQL-Variablen. Bekommst du Daten, die nicht dir gehören, selbst nur Metadaten?
• Input-Guardrails: Für Schlüssel-Felder (Email, Name, Search, File-Upload) teste überlange Strings, merkwürdiges Unicode und unerwartete Typen (Number statt String). Erzwingst du Längenlimits und Allowlists, wo sie wichtig sind?
• Geheimnis-Exposition: Durchsuche aktuelle Logs und Client-Bundles nach Tokens, API-Keys, JWTs oder "Authorization: Bearer". Prüfe auch Fehlerseiten. "War nur in Staging" wird oft zu "es wurde ausgeliefert".
• Injection-Oberflächen: Suche nach String-Konkatenation in SQL, Filtern, Template-Rendering, Shell-Commands oder Redirect-URLs. Wenn Input eines davon erreicht ohne starke Validierung, gehe von Risiko aus, bis du das Gegenteil beweist.

Schreibe die Top-3-Fixes auf, die du diese Woche ausliefern kannst, nicht eine Wunschliste. Beispiel: (1) Rate-Limiting für Login und Passwort-Reset hinzufügen, (2) serverseitige Ownership-Checks beim "get by id" Endpoint erzwingen, (3) Input-Längen begrenzen und unerwartete Zeichen für das Suchfeld ablehnen.

Nächste Schritte: Mache diese Checkliste zum Teil deines Build-Prozesses

Ein Spot-Check zahlt nur dann, wenn die Ergebnisse beeinflussen, was du auslieferst. Behandle diese Checkliste als kleinen, wiederholbaren Build-Schritt, nicht als einmalige Rettungsaktion.

Mach aus jedem Befund ein Backlog-Item, das schwer misszuverstehen ist:

• Fix: Was im Code oder in der Konfiguration geändert wird
• Test: Wie du beweist, dass es behoben ist (eine Anfrage, ein Unit-Test, ein QA-Schritt)
• Owner: Eine verantwortliche Person
• Zieltermin: Nächstes Release oder ein konkreter Tag
• Evidence: Datei/Endpoint und die exakte Anfrage/Payload, die das Problem gezeigt hat

Wähle eine Kadenz, die zu deinem Risiko und Team passt. Für viele Teams ist jedes Release ideal. Wenn Releases häufig sind, mache monatlich einen 30–60 Minuten-Review und eine kürzere Prüfung vor dem Shipping.

Erleichtere Wiederholbarkeit durch ein wiederverwendbares Prompt-Pack und eine Checklisten-Vorlage. Halte Prompts fokussiert auf konkrete Outputs: zeig die Route, die Guard, die fehlschlagende Anfrage und das erwartete Verhalten. Speichere das Pack dort, wo dein Team ohnehin arbeitet, damit es nicht übergangen wird.

Wenn du Apps per Chat entwickelst, verankere die Checkliste bereits in der Planung. Füge eine kurze "Security assumptions"-Notiz für Authn/Authz, Eingaben und Geheimnisse hinzu und führe den Spot-Check direkt nach der ersten lauffähigen Version aus.

Plattformen wie Koder.ai (koder.ai) passen gut zu dieser Gewohnheit, weil sie schnelle Iteration erlauben und Review-Checkpoints erhalten. Snapshots und Rollback um riskante Änderungen herum machen es leichter, Security-Fixes auszuliefern, ohne in Schwierigkeiten zu geraten, wenn sich Verhalten ändert.