𝗦𝗲𝗰𝘂𝗿𝗶𝘁𝘆-𝗔𝘂𝗱𝗶𝘁-𝗘𝗿𝗴𝗲𝗯𝗻𝗶𝘀𝘀𝗲: 𝗪𝗮𝗿𝘂𝗺 𝗶𝗰𝗵 𝗺𝗶𝗰𝗵 𝗴𝗲𝘀𝗰𝗵ä𝗺𝘁 𝗵𝗮𝗯𝗲
Ich habe vor Kurzem ein Security-Audit für alle meine Nebenprojekte durchgeführt. Dies umfasst mein FastAPI-Backend, Telegram-Bots, meine PWA und Streamlit-Apps.
Ich dachte, mein Code sei sicher, weil ich vorsichtig war. Ich habe mich geirrt.
Ich teile diese echten Produktionsfehler mit euch, um euch zu helfen, sie zu vermeiden. Das sind keine theoretischen Checklisten. Das sind Fehler, die ich tatsächlich gemacht habe.
Die Falle der bedingten Authentifizierung Ich habe Code geschrieben, der prüfte, ob ein API-Secret existiert, bevor er es verifizierte. Wenn die Umgebungsvariable fehlte, wurde die Prüfung komplett übersprungen. Das bedeutete, dass meine gesamte API öffentlich zugänglich war. Regel: Wenn ein Secret fehlt, schlage hart mit einem 500er-Fehler fehl. Überspringe niemals die Authentifizierung.
Das Leak in der Git-Historie Ich habe einmal für einen schnellen Test einen API-Key hardcodiert. Später habe ich ihn in eine .env-Datei verschoben und dachte, das Problem sei gelöst. Aber Git merkt sich alles. Jeder kann diesen Key in meiner Commit-Historie finden. Regel: Wenn du einen Key committest, geh davon aus, dass er gestohlen wurde. Rotiere ihn sofort. Nutze
git-filter-repo, um deine Historie zu bereinigen.Das Leak des Debug-Endpoints Ich habe einen
/debug/config-Endpoint in der Produktion gelassen, um bei der Fehlersuche zu helfen. Er legte meine Datenbank-URLs und Umgebungseinstellungen offen. Regel: Entferne alle Debug-Endpoints vor dem Deployment. Nutze stattdessen Logs.Systeminformationen durch Fehlermeldungen preisgeben Ich habe
str(e)in meinen Error-Responses verwendet. Dadurch wurden Datenbankfehler und Dateipfade direkt an den Benutzer gesendet. Angreifer nutzen dies, um deine Infrastruktur zu kartieren. Regel: Protokolliere den detaillierten Fehler für dich selbst. Sende dem Client eine generische Meldung wie „Internal Server Error“.Das XSS-Risiko im Frontend Ich habe
innerHTMLverwendet, um Benutzerinhalte zu rendern. Dies ermöglichte es Skripten, in den Browsern anderer Benutzer auszuführen. Regel: Escape HTML immer. BetrachteinnerHTMLals eine Möglichkeit, beliebigen Code auszuführen.Fehlende Rate Limits Ich hatte Endpoints, die teure KI-Modelle ohne jegliche Limits aufriefen. Eine einzige Schleife oder ein gestohlener Key könnte mich hunderte von Dollar kosten. Regel: Authentifizierung stoppt unbefugte Benutzer. Rate Limiting verhindert, dass autorisierte Benutzer dein System missbrauchen.
Zu permissive CORS-Policy Ich habe
allow_origins=["*"]in der Produktion verwendet. Dies erlaubt es jeder Website, Anfragen an deine API zu stellen. Regel: Erlaube nur deine spezifische Frontend-Domain.Das Leck durch temporäre Dateien Wenn mein Code während der Verarbeitung einer Datei abstürzt, bleibt die temporäre Datei für immer auf der Festplatte. Das verschwendet Speicherplatz und führt zum Abfluss sensibler Daten. Regel: Verwenden Sie
try-finally-Blöcke, um sicherzustellen, dass Dateien auch dann gelöscht werden, wenn ein Fehler auftritt.
Meine neue obligatorische Checkliste:
Vor dem Programmieren:
• Erstellen Sie eine .gitignore
• Erstellen Sie eine .env.example
Für jeden Endpunkt: • Fügen Sie Authentifizierung hinzu • Verwenden Sie generische Fehlermeldungen • Fügen Sie Rate Limits für rechenintensive Aufgaben hinzu
Vor dem Commit: • Scannen Sie Ihren Diff nach Secrets
Vor dem Deployment: • Führen Sie Sicherheitsaudits für Ihre Abhängigkeiten durch
Sicherheitsprobleme passieren nicht durch Zufall. Sie entstehen durch „TODO“-Kommentare und „temporäre“ Fixes, die für immer in der Produktion bleiben.
Einen Bug zu beheben ist langweilig. Eine Sicherheitsverletzung zu beheben ist teuer.