Normen für sichere Systementwicklung / Secure System Development

Falls in der Ausführungsumgebung eine globale Sperre für Assets besteht (die es verbietet, bestimmte eigene Assets anzugreifen/zu scannen), hat die globale Konfiguration Vorrang; dieser Skill überschreibt sie nicht. Siehe references/internal-policy.example.md für eine allgemeine Vorlage (die veröffentlichte Version enthält keine tatsächlichen internen Adressen).

Verwendung

Lesen Sie vor dem Schreiben von Code die „Rote-Linien-Liste“; überprüfen Sie sich selbst nach dem Schreiben. Lesen Sie beim Entwurf und der Überprüfung „Phase 1“. Wenn bestimmte Module betroffen sind, öffnen Sie die entsprechende Datei unter references/. Führen Sie vor dem Einreichen die „Bewertung vor dem Start“ durch. Überprüfen Sie nach dem Start die „Laufzeit und 0-Day“.

Wenn eine Aufgabe nur einen Teil betrifft (z. B. nur eine Anmeldeschnittstelle schreiben, nur eine Bestelltabelle entwerfen), lesen Sie nur das entsprechende Kapitel und die entsprechende Referenz; rezitieren Sie nicht alles auswendig.

Ausführbare Selbstüberprüfung (empfohlen, zuerst auszuführen)

python scripts/scan_redlines.py <Zielverzeichnis> --format text            # Menschlich lesbar
python scripts/scan_redlines.py <Zielverzeichnis> --format sarif --fail-on high   # CI-Blockade
python scripts/scan_redlines.py <Zielverzeichnis> --code-only              # Nur Code scannen, Dokumente überspringen

Reine Python-Standardbibliothek, keine Abhängigkeiten erforderlich. Deckt 18 Regeltypen ab, darunter SQL-Konkatenation, innerHTML/eval, CORS-Platzhalter und Reflexion, globales Fallback zur Startseite, hartcodierte Schlüssel, MD5-Passwortspeicherung, Befehlsinjektion, deaktivierte Zertifikatsprüfung, Debug-Schalter, sensible Felder in Logs, nicht validierte Upload-Pfade usw. Die Ergebnisse verweisen auf die entsprechende Referenz.

Fehlalarme: Fügen Sie am Ende der betreffenden Zeile einen Kommentar redline: ignore (ignoriert die gesamte Zeile) oder redline: ignore SQL001 (ignoriert nur die angegebene Regel) hinzu. Deaktivieren Sie nicht die gesamte Regel, um den Alarm zu beseitigen – notieren Sie den Grund und erläutern Sie ihn bei der Überprüfung.

Zwei Vorlagen: assets/threat-model-template.md (Bedrohungsmodellierung während der Entwurfsphase), assets/review-checklist.md (Checkliste für den Start nach Projekttyp).

Bestimmen Sie zuerst den Projekttyp (entscheidet, welche Regeln gelten)

Szenario	Typische Form	Sicherheitsregeln	Integritätsanforderung	Indexierung (SEO)
Öffentliche Website	Homepage, Landingpage, Blog, Dokumentation, Shop-Frontend	Vollständig	Niedrig (Inhalt öffentlich)	Obligatorisch: Echte 404, Sitemap, Canonical, Strukturierte Daten
Produkt nach Login	SaaS, Tool-Website, Community-Benutzeroberfläche	Vollständig + komplettes Kontosystem	Mittel (Signatur vertraulicher Aktionen)	Nur öffentliche Seiten übermitteln (Marketing/Hilfe); private Seiten noindex
Admin-Backend	Admin, Betriebs-Backend, Kunden-/Prüfsystem	Vollständig + separater Zugang + MFA + Prüfprotokolle	Hoch (Signatur aller Schreibvorgänge + Prüfung)	Indizierung verboten: Ganze Seite noindex + obligatorische Authentifizierung
Internes/Persönliches System	Interne Plattform, Eigenbautool, Skript-Panel, Home-NAS	Authentifizierung + minimale Exposition + Ratenbegrenzung + rechtzeitige Updates	Mittel (je nach Expositionsfläche)	Indizierung verboten: Nicht unter dem Standardpfad des öffentlichen Netzes ablegen; sich nicht auf „Verstecken“ als Sicherheit verlassen
Reine API	REST / GraphQL / Dienst-zu-Dienst-Aufrufe	Authentifizierung + Eingabevalidierung + Ratenbegrenzung + Versionsverwaltung	Nach Geschäft festlegen (Zahlung/Fonds hoch)	Nicht anwendbar (keine Seiten)

Es gibt nur eine Frage zur Bestimmung: Sollte diese URL in Suchmaschinen erscheinen?

Ja → Als öffentliche Website behandeln, SEO-Kapitel vollständig anwenden.
Nein → „Indizierung verboten“ umsetzen: X-Robots-Tag: noindex für die gesamte Seite, robots-Crawling verbieten, obligatorische Authentifizierung. SEO-Optimierung (Sitemap, Canonical, Strukturierte Daten) NICHT auf Backend- oder persönliche Systeme anwenden – das ist Verschwendung und vergrößert die Angriffsfläche.
Unabhängig vom Szenario: „Nicht vorhandene Pfade geben echten 404 zurück“ muss befolgt werden – das ist HTTP-Korrektheit, nicht SEO.

Fünf Grundprinzipien

Alle Eingaben sind unvertrauenswürdig: URL, Query, Body, Header, Cookie, hochgeladene Dateien, Webhook, Nachrichtenwarteschlange, Rückgabewerte von Drittanbieter-APIs, sogar historisch verunreinigte Daten aus der Datenbank.
Standardmäßig ablehnen (fail closed): Bei Fehlern in der Authentifizierung/Validierung/Parsing ablehnen, nicht durchlassen; Ausnahmepfade dürfen nicht zu einem „Überspringen der Prüfung“-Zweig führen.
Minimale Rechte: Datenbankkonten nach Funktion getrennt (Lese-/Schreibtrennung, kein DDL), Cloud-IAM/Objekt-Speicher nach Präfix autorisieren, Prozesse als Nicht-Root ausführen, Container mit schreibgeschütztem Dateisystem.
Tiefenverteidigung: Wenn eine Schicht versagt, ist die nächste noch aktiv. Frontend-Validierung ist Benutzererfahrung, serverseitige Validierung ist Sicherheit; WAF ist Absicherung, kein Ersatz.
Explosionsradius begrenzen: 0-Days können nicht durch Codekonventionen verhindert werden, aber durch Isolierung, Berechtigungsbeschränkung, ausgehende Whitelist, schnelle Patch-Kanäle auf ein Minimum reduziert werden.

Rote-Linien-Liste (hart, Punkt für Punkt selbst prüfen)

Authentifizierung und Sitzungen

Passwörter mit Argon2id/bcrypt(Kosten≥12)/scrypt hashen; MD5/SHA1/umkehrbare Verschlüsselung sind verboten
Fehlgeschlagene Anmeldungen nach „Konto + IP“ dual begrenzen, progressive Verzögerung, ggf. CAPTCHA/temporäre Sperrung
Antworttext und Verzögerung bei Anmeldung/Registrierung/Passwort-Wiederherstellung konsistent halten; keine Information preiszugeben, ob das Konto existiert
Nach erfolgreicher Anmeldung die Sitzungs-ID rotieren (gegen Session Fixation); Cookie mit HttpOnly + Secure + SameSite
JWT serverseitig mit fester Algorithmus-Whitelist; alg:none und Algorithmus-Verwirrung ablehnen; kurze Gültigkeitsdauer + Refresh-Rotation + Widerrufbarkeit
Authentifizierung ≠ Autorisierung: Jede Schnittstelle explizit prüfen, ob der aktuelle Benutzer das Objekt bearbeiten darf (gegen IDOR/Privilege Escalation)

Injektion und Ausgabe

Alle SQL-Abfragen mit parametrisierten Abfragen/ORM-Bindung; String-Konkatenation verboten; Tabellennamen/Sortierfelder über Whitelist-Mapping
Benutzereingaben niemals in Shells/Befehle einfügen; execFile-Familie mit Parameter-Array verwenden
Ausgabe je nach Kontext kodieren; dangerouslySetInnerHTML/v-html/innerHTML muss über DOMPurify o.ä. Sanitizer gehen
Rich-Text, Markdown, URL-Parameter immer whitelisten; keinem Frontend-Filter vertrauen
Ausgehende Anfragen (SSRF) über Whitelist; keinem willkürlichen Redirect folgen; interne/Metadaten-Adressen blockieren (169.254.169.254, 127.0.0.1, 10/8, 172.16/12, 192.168/16, ::1, file://, gopher://)
Dateipfade mit path.resolve prüfen und Präfix validieren; .. ablehnen; hochgeladene Dateien zufällig benennen, Typ-Sniffing, isoliert speichern, keine Ausführungsrechte

Daten und Nebenläufigkeit

Kritische Schreibvorgänge idempotent gestalten (eindeutiger Index / Idempotenz-Schlüssel); Bestellungen, Zahlungen, Callbacks müssen idempotent sein
Felder wie Lagerbestand, Guthaben, Anzahl mit bedingtem Update UPDATE ... WHERE Rest >= ?; keine „Erst lesen, dann ändern“-Muster
Transaktionen kurz halten; innerhalb von Transaktionen keine Netzwerkaufrufe, Nachrichtenversand oder Template-Rendering
Neue Abfragen müssen mit EXPLAIN validiert werden; große OFFSET-Paginierung, SELECT *, N+1-Abfragen verboten
Beträge als Ganzzahlen in Cent oder DECIMAL speichern; float/double verboten

Asynchronität und Stabilität

Alle externen Aufrufe (HTTP/DB/Redis/MQ) explizit mit Timeout versehen; kein unbegrenztes Warten
Wiederholungen nur für idempotente Operationen; exponentielles Backoff + Jitter + Obergrenze
Nachrichtenverarbeitung idempotent (message_id-Deduplizierungstabelle); Fehler in Dead-Letter-Queue und Alarmierung
Kritische Statusänderungen zuerst in die Datenbank schreiben, dann Nachricht senden (Outbox/Transaktionsnachrichten); kein Doppelschreiben

Geschäftslogik und Wettlaufsituationen (am häufigsten übersehen)

Preise, Beträge, Rabatte, Berechtigungsstufen immer serverseitig berechnen; vom Client übermittelte Werte nur zur Anzeige verwenden
Coupons/Einlösecodes/Einladungscodes an Benutzer und Anzahl binden; atomare Abrechnung (bedingtes Update oder eindeutige Einschränkung)
Zustandsmaschine explizit prüfen: Illegale Übergänge direkt ablehnen (z. B. „Pending“ umgeht Zahlungs-Callback und wird direkt „Bezahlt“)
Zahlungs-/Callback-Schnittstellen prüfen: Signatur + Zeitstempel + Idempotenz-Schlüssel; gegen Replay und Fälschung
Kaufbeschränkung/Ratenbegrenzung nach „Benutzer + Gerät + IP“-Kombination; nicht nur nach einer Dimension umgehen
Export-/Batch-/Suchschnittstellen: Ratenbegrenzung + Datenmengenobergrenze + Prüfung

Schlüssel und Betrieb

Schlüssel nur in Umgebungsvariablen oder Schlüsselverwaltungsdiensten; nicht in Repository, Image-Layer, Frontend-Bundle, Logs, Fehlermeldungen
CI/CD-Anmeldedaten mit minimalen Rechten; Produktionsdeployment benötigt Genehmigung; Drittanbieter-Abhängigkeiten mit gesperrten Versionen + Scannen
Vertrauliche Aktionen (Anmeldung, Rechteänderung, Export, Löschung, Rückerstattung) in Prüfprotokollen aufzeichnen; durch Geschäftscode nicht manipulierbar

API-Integrität (gegen Abfangen/Manipulation/Replay/gefälschte Antworten)

Vertrauliche Anfragen (Zahlung, Berechtigung, Autorisierung, Passwortänderung) signieren: HMAC(secret, method+path+sortedQuery+sha256(body)+timestamp+nonce); serverseitig neu berechnen
Nonce-Speicher deduplizieren (TTL = Zeitfenster); Zeitfenster ±300s; abgelaufene und wiederholte Nonces ablehnen
Vertrauliche Antworten (Zahlungsergebnis, Autorisierungsergebnis, Guthaben) serverseitig signieren; Client prüft; aber die Wahrheit liegt immer in der serverseitigen Nachprüfung
Vom Client übermittelte „überprüfte“ Markierungen, Preise, Rollen nie als Wahrheitsquelle betrachten; serverseitig neu berechnen/überprüfen
Mobile: Zertifikat-Pinning; Release-Builds dürfen Benutzerzertifikate nicht vertrauen, Debug-/Packet-Capture-Schalter nicht aktivieren
Client-Härtung (Obfuskation/Härtung/Anti-Debugging) erhöht nur die Kosten, ist keine Sicherheitsgrenze; Schlüssel nicht an den Client ausliefern

AI / LLM-Anwendungen

Modellausgabe als unvertrauenswürdige Eingabe behandeln: Nicht eval, nicht direkt in HTML/SQL/Befehle einfügen, nicht direkt Tool-Parameter ausführen
Tool-/Funktionsaufrufe mit minimalen Rechten + Parameter-Schema-Validierung + hochriskante Aktionen mit menschlicher Bestätigung
RAG-abgerufene Dokumente als unvertrauenswürdigen Inhalt behandeln, vom System-Prompt trennen; gegen indirekte Prompt-Injektion
System-Prompt und Benutzereingabe trennen; Schlüssel und interne Regeln nicht an Stellen ablegen, die zur Ausgabe verleitet werden können
Ratenbegrenzung nach Benutzer/Mandant für Kosten und Frequenz; Logs schwärzen (keine sensiblen Daten aus vollständigen Prompts aufzeichnen)

Mobile Apps / Mini-Programme

Vertrauliche Daten im Keychain (iOS) / Keystore (Android) speichern; keine Klartext-SharedPreferences
Übertragung mit TLS + Zertifikat-Pinning erzwingen; InsecureSkipVerify/verify=False sind grundsätzlich verboten
WebView: Dateizugriff und JS-Bridge-Exposition deaktivieren; onShouldStartLoadWithRequest mit Domain-Whitelist
Mini-Programm session_key nur serverseitig verwenden; niemals an das Frontend ausliefern; nach code2session eigene Sitzung ausstellen
Root-/Jailbreak-Erkennung nur als Risikosignal, nicht als Authentifizierungsgrundlage

HTTP und Routing (alle Szenarien)

Nicht vorhandene Pfade geben echten HTTP 404 + 404-Seite zurück; 302/200-Umleitungen auf die Startseite verboten
SPA-History-Fallback nur für „bekannte Frontend-Routen“ aktivieren; /api und statische Ressourcen mit Dateierweiterung geben immer 404
CORS mit präziser Origin-Whitelist; Access-Control-Allow-Origin: * in Kombination mit Credentials verboten; willkürliche Origin-Reflexion verboten
Produktion: Sicherheits-Response-Header aktivieren: HSTS, CSP, X-Content-Type-Options, Referrer-Policy, frame-ancestors
Antworten von authentifizierten/vertraulichen Schnittstellen mit Cache-Control: no-store
Fehlerantworten geben keinen Stacktrace, SQL, Framework-Version oder interne Pfade preis

Indexierung (nur für öffentliche Websites erforderlich; Backend-/interne Systeme umgekehrt)

Öffentliche Websites: Sitemap nur mit 200-Seiten; Canonical zur Deduplizierung; Robots nicht Backend-Pfade preisgeben; Staging-Umgebung gesamte Seite noindex
Backend-/interne/persönliche Systeme: Gesamte Seite X-Robots-Tag: noindex + robots Disallow: /; keine Sitemap generieren; obligatorische Authentifizierung (robots ist keine Zugriffskontrolle)

Phase 1: Während des Entwurfs

Nehmen Sie sich vor dem Beginn 5 Minuten für eine leichte Bedrohungsmodellierung:

Szenario bestimmen: Vergleichen Sie mit der Projekttypentabelle oben; stellen Sie fest, ob es sich um eine öffentliche Website, ein Backend, ein internes System oder eine API handelt; entscheiden Sie basierend darauf, ob das SEO-Kapitel ausgeführt wird und wie groß die Expositionsfläche ist.
Datenfluss zeichnen: Benutzer → Gateway → Dienst → Datenbank/Cache/MQ/Drittanbieter; markieren Sie jeden Punkt, der eine Vertrauensgrenze überschreitet.
Assets auflisten und klassifizieren: Konto, Anmeldedaten, Zahlung, persönliche Daten, Admin-Backend; fragen Sie sich: „Wer kann lesen, wer kann schreiben, welche Konsequenzen hat eine Manipulation, wie lange aufbewahren?“.
An jeder Grenze drei Fragen stellen: Wer kann hier ankommen? Wird die Eingabe validiert? Wird bei Fehlern standardmäßig abgelehnt?
Berechtigungsmodell festlegen: Rolle → Ressource → Aktion; serverseitig erzwingen; ausgeblendete Buttons im Frontend reichen nicht; bei Multi-Mandanten-Systemen zusätzliche Isolierungsstrategie festlegen.
Asynchrone Grenzen festlegen: Welche Operationen müssen synchron zurückgegeben werden (Anmeldung, Zahlungsbestätigung), welche können asynchron sein (Benachrichtigung, Bericht, Export).

Das Entwurfsdokument sollte mindestens enthalten: Projekttyp und Indexierungsstrategie, Authentifizierungsmethode, Autorisierungsmodell, Klassifizierung und Verschlüsselung sensibler Daten, Ratenbegrenzungsstrategie, Idempotenz-Schlüssel, Fehlerbehandlungsstrategie, Umfang der Protokollierung und Prüfung.

Phase 2: Während der Implementierung

Authentifizierung und Anmeldung (höchste Priorität)

Die Anmeldung ist der am häufigsten bruteforcierte, mit Credential-Stuffing angegriffene und umgangene Einstiegspunkt. Vollständige Regeln in references/auth-and-session.md, nicht verhandelbar:

Gestaffelte Ratenbegrenzung: Einzelne IP, einzelnes Konto, einzelner Geräte-Fingerabdruck; Fehlerzähler mit Redis-Ablaufschlüsseln, nicht nur im Speicher.
Fehlermeldungen einheitlich als „Konto oder Passwort falsch“; Verzögerung angleichen (auch bei nicht existierendem Konto einen falschen Hash durchführen, um Timing-Angriffe zu verhindern).
Nach erfolgreicher Anmeldung Sitzungskennung neu generieren; alte Sitzung ungültig machen.
Vertrauliche Aktionen (Passwortänderung, Änderung der gebundenen Daten, Auszahlung, Löschung) erfordern eine zweite Verifizierung oder eine Überprüfung des letzten Authentifizierungszeitpunkts (Re-Auth-Fenster).
Passwort-Zurücksetzen-Token: Hohe Entropie, einmalig, kurze Gültigkeitsdauer (≤15 Minuten), an Benutzer und Verwendungszweck gebunden.
Admin-Backend: separater Zugang, separate Domain oder IP-Whitelist; keine gemeinsame Sitzung mit der Benutzerseite.

Eingabe, Injektion und Ausgabe

Siehe references/web-vulnerability-prevention.md. Prinzip: Einheitliche Eingabevalidierung (Schema), Ausgabe je nach Kontext kodieren.

// Eingabe: Schema-Validierung; unbekannte Felder ablehnen, nicht nur „die benötigten nehmen“
const LoginBody = z.object({ email: z.string().email(), password: z.string().min(8).max(128) }).strict();

// SQL: Parametrisiert, niemals konkatenieren
await db.query('SELECT id, password_hash FROM users WHERE email = $1', [email]);
// Für Positionen wie Sortierung/Tabellennamen, die nicht parametrisiert werden können: Whitelist
const orderBy = { created_at: 'created_at', amount: 'amount_cents' }[sort] ?? 'created_at';

XSS: React/Vue standardmäßig escapen; gefährliche APIs müssen sanitize; CSP als zweite Verteidigungslinie.
Privilege Escalation: Abfragebedingung owner_id = $currentUser einfügen; nicht „nach dem Abruf im Frontend prüfen“.
Deserialisierung/Template-Injektion: Nicht eval; Benutzereingabe nicht in Templates/Regex/Ausdrücke einfügen.
Upload: Größe und Typ begrenzen (nach Magic-Bytes-Sniffing); zufällige Dateinamen; in Objektspeicher ablegen; Bilder neu codieren.

Datenbank und hohe Nebenläufigkeit

Siehe references/database-concurrency.md. Wichtige Punkte:

Indizes vor Optimierung: Neue Abfragen vor dem Start mit EXPLAIN prüfen; auf type=ALL, filesort, temporäre Tabellen achten.
Paginierung mit Cursor (keyset); keine tiefen OFFSET; Listenschnittstellen müssen stabile Sortierung + Obergrenze haben.
Heiße Schreibvorgänge mit „bedingtem Update + Zeilensperre“; Beispiel für Lagerbestandsreduzierung:

UPDATE sku SET stock = stock - $1, version = version + 1
WHERE id = $2 AND stock >= $1;
-- Betroffene Zeilen = 0 → Lagerbestand nicht ausreichend oder Nebenläufigkeitskonflikt; je nach Geschäft wiederholen/fehlschlagen

Cache-Dreiklang: Gegen Cache-Durchbruch (Leerwert-Caching/Bloom-Filter), Cache-Zusammenbruch (Mutex-Sperre/Einzelflug), Cache-Überschwemmung (TTL mit zufälligem Jitter).
Verbindungspool-Obergrenze kleiner als Datenbank max_connections / Anzahl der Instanzen; Timeout für Abruf konfigurieren.
Erst wenn der Maßstab wächst, über Sharding nachdenken; zuerst Indizes, Cache, Lese-/Schreibtrennung, Kalt-/Warmtrennung.

Geschäftslogik und Wettlaufsituationen

Siehe references/business-logic-and-race-conditions.md. Für diese Art von Schwachstellen gibt es keinen universellen Scanner; sie müssen während des Entwurfs Punkt für Punkt durchdacht werden: Preise und Beträge serverseitig berechnen, Coupon-atomare Abrechnung, Zustandsmaschinenprüfung, Replay-Schutz, Kaufbeschränkungsdimension, Export-Ratenbegrenzung. Das Muster „Erst lesen, dann schreiben“ unter Nebenläufigkeit immer in ein bedingtes Update oder Sperre + Idempotenz ändern.

Asynchrone Prioritätsarchitektur

Siehe references/async-architecture.md. Standardmäßig asynchron entwerfen:

E/A alle nicht blockierend; in Node.js synchrone fs/crypto und schwere CPU-Berechnungen (mit worker_threads) im Anforderungspfad verboten.
Jeder externe Aufruf muss einen Timeout haben; trace id in der Aufrufkette weitergeben.
Warteschlangenkonsum = mindestens einmalige Zustellung, daher muss idempotent sein; Wiederholungen mit Obergrenze; bei Überschreitung in DLQ und Alarmierung.
Dienstübergreifende Konsistenz mit Outbox/CDC, kein Doppelschreiben.
Lange Aufgaben (Export, Batch, Prüfung) in die Warteschlange; Schnittstelle gibt sofort Aufgaben-ID zurück; Frontend pollt oder SSE-Push-Status.
Graceful Shutdown: Keine neuen Anfragen annehmen → laufende abschließen → Warteschlangenkonsumenten schließen → Verbindungen schließen.

HTTP, Routing, CORS und SEO

Siehe references/http-routing-cors-seo.md. Drei häufigste Fehler:

404 muss 404 sein. Kein globales Fallback auf die Startseite: SPA nur für bekannte Build-Routen auf index.html zurückfallen; /api/* und Pfade mit Dateierweiterung direkt 404.
CORS präzise Whitelist: Origin mit Konfigurationselementen auf Gleichheit prüfen; nicht includes, nicht Präfix-Match, nicht Anforderungsheader direkt zurückspiegeln.
Statuscodes semantisch korrekt: 401 nicht authentifiziert, 403 keine Berechtigung, 404 nicht vorhanden, 409 Konflikt, 422 Validierungsfehler, 429 Ratenbegrenzung.

SEO gilt nur für öffentliche Websites; Backend- und interne Systeme gemäß der Szenarientabelle oben als „Indizierung verboten“ behandeln; keine Sitemap, Canonical, Strukturierte Daten hinzufügen – das vergrößert die Angriffsfläche für Crawler.

Schlüssel, Betrieb und E-Mail

Siehe references/operations-and-secrets.md. Wichtige Punkte: Schlüssel gestaffelt speichern und rotieren; CI/CD mit minimalen Rechten; Container als Nicht-Root; Objektspeicher und Cloud-IAM minimieren; Prüfprotokolle nicht manipulierbar; E-Mail-Domain mit SPF/DKIM/DMARC gegen Fälschung konfigurieren; Datenaufbewahrungsfrist und Löschprozess.

API-Integrität und Manipulationsschutz

Siehe references/api-integrity-and-tampering.md. Abfangen/Manipulieren von Paketen und Replay sind die Hauptprobleme bei mobilen und offenen APIs: Anforderungssignatur (HMAC + timestamp + nonce + body hash); serverseitig neu berechnen; vertrauliche Antworten signieren; nonce deduplizieren; Zeitfenster; Zertifikat-Pinning. Denken Sie daran: Alles, was der Client ändern kann, ist unvertrauenswürdig; die Signatur erhöht nur die Hürde, die serverseitige Neuberechnung ist die Wahrheit.

AI / LLM-Anwendungssicherheit

Siehe references/ai-llm-security.md. Modellausgabe gleichwertig mit externer Eingabe: Nicht ausführen, nicht direkt einfügen, nicht als SQL/Befehl behandeln; Tool-Aufrufe mit minimalen Rechten + Schema-Validierung + hochriskante Aktionen mit menschlicher Bestätigung; RAG-Inhalte unvertrauenswürdig; Ratenbegrenzung nach Mandant zur Kostenkontrolle.

Mobile Apps und Mini-Programme

Siehe references/mobile-and-miniprogram.md. Keychain/Keystore, Zertifikat-Pinning, WebView-Härtung, Mini-Programm session_key nicht ausliefern, Root-Erkennung nur als Signal.

Phase 3: Bewertung vor dem Start

Der Reihe nach durchgehen; jeder Punkt, bei dem „nicht sicher“, gilt als nicht bestanden:

Rote-Linien-Liste zu 100 % abgehakt; dann nach Projekttyp prüfen: öffentliche Website SEO-Punkte prüfen, Backend-/interne Systeme noindex und Zugangsisolierung prüfen, sensible Geschäfte API-Integrität prüfen.
python scripts/scan_redlines.py <Verzeichnis> --fail-on high ausführen; hohe Risiken müssen auf Null reduziert werden.
Abhängigkeitsscan (npm audit / pip-audit / govulncheck / OWASP Dependency-Check); hohe Risiken müssen behandelt werden.
Schlüsselprüfung: Keine Schlüssel im Repository, Image, Logs, Frontend-Bundle; .env nicht im Versionskontrollsystem; CI-Logs ebenfalls prüfen.
Container/Host: Nicht-Root, schreibgeschütztes Root-Dateisystem, minimale Port-Exposition, ausgehende Whitelist.
Überwachung und Alarmierung: Anmeldefehlerrate, 5xx, Warteschlangenstau, langsame Abfragen, ungewöhnliche ausgehende Anfragen.
Backup- und Wiederherstellungsübung; Datenbankkonten mit minimalen Rechten.
Belastungstest kritischer Pfade (Anmeldung, Bestellung, Liste) zur Bestätigung der Ratenbegrenzung und des Caches.
E-Mail-Domain: SPF/DKIM/DMACK konfigurieren; E-Mail-Schnittstelle mit Ratenbegrenzung; vermeiden, dass sie zum Versenden von Phishing-E-Mails oder als Spam-Quelle verwendet wird.
Datenlebenszyklus: Minimale Erfassung festlegen; Aufbewahrungsfrist; Export- und Löschprozess; Logs nach Schwärzung aufbewahren.
Sicherheitsreaktionsplan: Wer ist verantwortlich, wie isolieren, wie Benutzer benachrichtigen, wie nachbereiten.
Compliance-Mapping (falls erforderlich): Prüfen Sie references/compliance-mapping.md auf OWASP/ASVS/etc./PIPL-Punkte.

Phase 4: Laufzeit und 0-Day-Minderung

Codekonventionen verhindern keine unbekannten Schwachstellen; die Auswirkungen werden durch folgende Maßnahmen begrenzt:

Ausgehend standardmäßig ablehnen + Whitelist (erste Barriere gegen SSRF, Rückverbindung der Lieferkette).
Kritische Dienste in Sandbox/Container isolieren; Prozessrechte herabsetzen; seccomp/AppArmor nach Bedarf aktivieren.
Abhängigkeiten mit gesperrten Versionen + schnell wiederherstellbare Images; Sicherheitsankündigungen verfolgen; Notfall-Patch-Kanal reservieren.
WAF/Gateway für allgemeine Signaturblockierung und Ratenbegrenzung, aber sich nicht darauf verlassen.
Verhaltensüberwachung: Ungewöhnliche Anmelde-Geo/Gerätesprünge, Batch-Lese-/Schreibvorgänge, ungewöhnlicher ausgehender Datenverkehr.
Datenklassifizierung: Vertrauliche Felder verschlüsselt speichern (AES-GCM/KMS); Logs schwärzen; Export mit Genehmigung.

references-Index

Datei	Wann lesen
`references/auth-and-session.md`	Anmeldung, Registrierung, Passwort, JWT, 2FA, Passwort-Wiederherstellung, CSRF, Privilege Escalation, Admin-Backend
`references/web-vulnerability-prevention.md`	SQL-Injektion, XSS, SSRF, Upload, Path Traversal, Deserialisierung, Response-Header, API-spezifische Risiken
`references/business-logic-and-race-conditions.md`	Preis/Betrag, Coupon, Lagerbestand, Zustandsmaschine, TOCTOU-Wettlauf, Kaufbeschränkung, Exportmissbrauch
`references/database-concurrency.md`	Tabellenerstellung, Indizes, Transaktionen, Sperren, Idempotenz, Cache, Lese-/Schreibtrennung, Sharding
`references/async-architecture.md`	Timeout, Wiederholung, Warteschlangenkonsum, Outbox, Backpressure, Graceful Shutdown, Beobachtbarkeit
`references/http-routing-cors-seo.md`	404, Statuscodes, CORS, Cache, robots/Sitemap, Indexierungstrennung zwischen öffentlichen Websites und Backend
`references/operations-and-secrets.md`	Schlüssel, CI/CD, Container-Cloud, E-Mail-Domain, Prüfprotokolle, Datenlebenszyklus, Notfall
`references/api-integrity-and-tampering.md`	Paketabfangen/Manipulation, Anforderungs-/Antwortsignatur, Replay-Schutz, Zertifikat-Pinning, Client-Härtungsgrenze
`references/ai-llm-security.md`	Prompt-Injektion, Tool-Aufrufberechtigungen, RAG-Vergiftung, Modellausgabeverarbeitung, Kostenratenbegrenzung
`references/mobile-and-miniprogram.md`	Lokaler Speicher, Zertifikat-Pinning, WebView, Mini-Programm-Anmeldestatus, Root-Erkennung
`references/compliance-mapping.md`	OWASP Top 10 / ASVS / etc. Level 2.0 / PIPL-Vergleich; für Audits oder Überprüfungspräsentationen
`references/internal-policy.example.md`	Bei Bedarf einer benutzerdefinierten Asset-Sperrvorlage (Platzhalter-Domain, keine echten Adressen)

Liefervereinbarungen

Geben Sie bei jeder Code-Lieferung in der Antwort in 3–6 Zeilen an, welche Sicherheitsentscheidungen in diesem Fall getroffen wurden (Prüfpunkte, Authentifizierungspunkte, Idempotenz-Schlüssel, Ratenbegrenzung, Fehlerbehandlung); nicht überspringen.
Geben Sie zuerst den Projekttyp an: Wenn ein Backend oder ein internes System geliefert wird, stellen Sie klar, dass „kein SEO, gesamte Seite noindex“ gilt; nur bei öffentlichen Websites werden indexierungsrelevante Konfigurationen ausgegeben.
Wenn Sie feststellen, dass vorhandener Code gegen eine rote Linie verstößt, zeigen Sie direkt die Stelle und den Fix auf; sagen Sie nicht nur „Empfehlung zur Härtung“.
Für Teile, die nicht verifiziert werden können (z. B. kein tatsächlicher Angriffstest durchgeführt), geben Sie explizit „nicht verifiziert“ an; behaupten Sie nicht, dass der Sicherheitstest bestanden wurde.

bucai2417/secure-system-development

Was ist secure-system-development?

In Ihrer bevorzugten KI fragen

Dokumentation