Was ein Sicherheitsaudit tatsächlich umfasst (und warum Ihre Anwendung eines braucht)

Sicherheit fühlt sich abstrakt an, bis sie es nicht mehr ist. Eine kompromittierte Kundendatenbank, ein offengelegter API-Schlüssel, eine SQL Injection in einem vergessenen Endpunkt — und plötzlich ist es das Einzige, was zählt.

Ein Sicherheitsaudit ist der Prozess, diese Schwachstellen zu finden, bevor jemand anderes es tut.

Der Stand der Anwendungssicherheit

Die Zahlen sind ernüchternd:

Die OWASP Top 10^[1] — die branchenweite Standardliste kritischer Sicherheitsrisiken für Webanwendungen — hat sich in ihrer Struktur seit der ersten Veröffentlichung nicht dramatisch verändert. Dieselben Kategorien von Schwachstellen treten immer wieder auf: Injection-Angriffe, fehlerhafte Authentifizierung, Offenlegung sensibler Daten und Sicherheitsfehlkonfigurationen.

Laut dem Cost of a Data Breach Report 2024 von IBM^[2] erreichten die globalen Durchschnittskosten einer Datenpanne 4,88 Millionen Dollar — der höchste jemals erfasste Wert. Der Bericht stellte auch fest, dass Organisationen, die Verstöße in weniger als 200 Tagen identifizierten, erheblich weniger zahlten als solche, die länger brauchten.

Der State of Software Security-Bericht von Veracode^[3] ergab, dass etwa 74 % der Anwendungen mindestens eine Sicherheitslücke aufweisen und rund 20 % schwerwiegende Lücken haben. Webanwendungen hatten die höchste Fehlerhaftigkeit.

Das sind keine theoretischen Risiken. Es sind statistische Gewissheiten für jede Anwendung, die Benutzerdaten verarbeitet.

Was ein Sicherheitsaudit umfasst

Ein umfassendes Sicherheitsaudit untersucht Ihre Anwendung über mehrere Dimensionen:

1. Authentifizierung und Autorisierung

Die kritischste Ebene. Ein Audit prüft:

• Passwortrichtlinien: Werden Passwörter mit modernen Algorithmen (bcrypt, Argon2) gehasht? Gibt es Mindestanforderungen an die Komplexität?
• Session-Management: Wie werden Sitzungen erstellt, aufrechterhalten und beendet? Sind Session-Tokens ausreichend zufällig? Laufen Sitzungen ab?
• Multi-Faktor-Authentifizierung: Ist MFA verfügbar? Wird es für Admin-Konten erzwungen?
• Autorisierungslogik: Kann Benutzer A auf die Daten von Benutzer B zugreifen, indem er eine ID in der URL ändert? (Das nennt sich IDOR — Insecure Direct Object Reference, und es ist erschreckend häufig.)
• API-Authentifizierung: Sind API-Tokens eingeschränkt, rotierbar und ordnungsgemäß validiert?
• OAuth-Flows: Bei Nutzung von Drittanbieter-Authentifizierung — werden Redirect-URIs validiert? Werden Tokens sicher gespeichert?

2. Eingabevalidierung und Injection

Jede Stelle, an der Ihre Anwendung Eingaben annimmt, ist ein potenzieller Angriffsvektor:

• SQL Injection: Kann ein Angreifer Datenbankabfragen über Formularfelder, URL-Parameter oder API-Payloads manipulieren?
• Cross-Site Scripting (XSS): Kann ein Angreifer JavaScript einschleusen, das in den Browsern anderer Benutzer ausgeführt wird?
• Command Injection: Wenn Ihre Anwendung Systembefehle ausführt — kann ein Angreifer zusätzliche Befehle einschleusen?
• Path Traversal: Kann ein Angreifer auf Dateien außerhalb des vorgesehenen Verzeichnisses zugreifen (z. B. ../../etc/passwd)?
• Datei-Upload-Validierung: Kann ein Angreifer ausführbare Dateien als Bilder getarnt hochladen?

3. Datenschutz

Wie Ihre Anwendung mit sensiblen Daten umgeht:

• Verschlüsselung im Ruhezustand: Sind sensible Daten in der Datenbank verschlüsselt?
• Verschlüsselung bei der Übertragung: Wird TLS überall erzwungen? Gibt es Mixed-Content-Probleme?
• Daten in Logs: Werden Passwörter, Tokens oder personenbezogene Daten versehentlich geloggt?
• Daten in URLs: Werden sensible Parameter in URLs übergeben (sichtbar in Browser-Verlauf und Server-Logs)?
• Backup-Sicherheit: Sind Datenbank-Backups verschlüsselt und zugriffskontrolliert?
• Umgang mit personenbezogenen Daten: Werden personenbezogene Daten nur dort gespeichert, wo nötig, und nur so lange wie nötig?

4. Infrastruktur und Konfiguration

Die Umgebung, in der Ihre Anwendung läuft:

• Serverkonfiguration: Sind unnötige Dienste deaktiviert? Wurden Standardzugangsdaten geändert?
• HTTP-Sicherheitsheader: Content-Security-Policy, X-Frame-Options, Strict-Transport-Security — sind sie korrekt gesetzt?
• Fehlerbehandlung: Geben Fehlerseiten Stack-Traces, Datenbankschemas oder interne Pfade preis?
• Schwachstellen in Abhängigkeiten: Gibt es bekannte CVEs in Ihrem Framework, Ihren Bibliotheken oder dem Betriebssystem?
• Container-Sicherheit: Bei Verwendung von Docker — basieren Images auf minimalen Basis-Images? Laufen Container als Non-Root?

5. Geschäftslogik

Technische Sicherheitstools übersehen Fehler in der Geschäftslogik:

• Rate Limiting: Kann ein Angreifer den Login brute-forcen, Tausende Passwort-Zurücksetzungs-E-Mails senden oder Ihre gesamte Datenbank scrapen?
• Race Conditions: Können zwei gleichzeitige Anfragen ungültige Zustände erzeugen (doppelte Ausgaben, doppelte Konten)?
• Privilege Escalation: Kann ein normaler Benutzer auf Admin-Funktionalität zugreifen, indem er Anfragen manipuliert?
• Preismanipulation: Kann ein Angreifer Preise, Mengen oder Rabattcodes in Zahlungs-Flows ändern?

Häufige Feststellungen

Nach Jahren der Durchführung und Beauftragung von Sicherheitsaudits sind dies die häufigsten Probleme, grob nach Häufigkeit geordnet:

1. Fehlendes oder schwaches Rate Limiting — Login-, Registrierungs- und Passwort-Zurücksetzungs-Endpunkte ohne Drosselung
2. Übermäßig permissive CORS — APIs, die Anfragen von jeder Origin akzeptieren
3. Sensible Daten in Logs — API-Tokens, Benutzer-E-Mails oder Request Bodies in Anwendungs-Logs
4. Fehlende Sicherheitsheader — Keine Content-Security-Policy, kein HSTS, kein X-Frame-Options
5. Veraltete Abhängigkeiten mit bekannten CVEs — npm-Pakete, Composer-Pakete oder Basis-OS mit veröffentlichten Schwachstellen
6. IDOR-Schwachstellen — Zugriff auf Ressourcen anderer Benutzer durch Ändern von IDs in API-Aufrufen
7. Unzureichende Eingabevalidierung — Vertrauen auf clientseitige Validierung ohne serverseitige Prüfungen
8. Standardzugangsdaten bei internen Tools — Admin-Panels, Monitoring-Dashboards oder Datenbankmanager mit Standardpasswörtern
9. Fehlende Audit-Protokollierung — Keine Aufzeichnung darüber, wer wann auf was zugegriffen hat
10. Unsichere Passwort-Zurücksetzungs-Flows — Tokens, die nicht ablaufen, vorhersehbar sind oder wiederverwendet werden können

So bereiten Sie sich auf ein Sicherheitsaudit vor

Vor dem Audit:

1. Dokumentieren Sie Ihre Architektur — Welche Dienste existieren, wie sie kommunizieren, wo Daten gespeichert werden
2. Listen Sie Ihre Abhängigkeiten auf — Führen Sie composer audit, npm audit oder das Äquivalent für Ihren Stack aus
3. Identifizieren Sie sensible Datenflüsse — Wo treten Benutzerdaten ein, wie werden sie verarbeitet, wo werden sie gespeichert?
4. Überprüfen Sie Zugriffskontrollen — Wer hat Zugang zu Produktions-Servern, Datenbanken und Drittanbieter-Diensten?
5. Prüfen Sie Ihre Sicherheitsheader — Verwenden Sie Tools wie securityheaders.com für eine schnelle Bestandsaufnahme

Nach dem Audit:

1. Priorisieren Sie Befunde nach Risiko — Kritische Schwachstellen zuerst (SQL Injection, Authentifizierungsumgehungen), informative Befunde zuletzt
2. Beheben Sie Probleme systematisch — Flicken Sie nicht nur Symptome; adressieren Sie Grundursachen
3. Verifizieren Sie Korrekturen — Testen Sie jede Schwachstelle nach der Behebung erneut
4. Aktualisieren Sie Prozesse — Fügen Sie Sicherheitsprüfungen zu Ihrer Code-Review-Checkliste und CI-Pipeline hinzu
5. Planen Sie das nächste Audit — Sicherheit ist ein fortlaufender Prozess, kein einmaliges Ereignis

Wie oft sollten Sie auditieren?

Der PCI DSS (Payment Card Industry Data Security Standard)^[4] verlangt jährliche Penetrationstests für Organisationen, die Zahlungsdaten verarbeiten. Auch wenn nicht alle Anwendungen unter PCI fallen, ist das Prinzip sinnvoll:

• Jährliches umfassendes Audit für jede Anwendung, die Benutzerdaten verarbeitet
• Vierteljhrliche automatisierte Scans auf bekannte Schwachstellen in Abhängigkeiten
• Kontinuierliche Überwachung auf neue CVEs, die Ihren Stack betreffen
• Ad-hoc-Audit nach größeren Architekturänderungen, neuen Integrationen oder Sicherheitsvorfällen

Das Fazit

Bei einem Sicherheitsaudit geht es nicht darum, herauszufinden, dass Sie unsicher sind — jede Anwendung hat Schwachstellen. Es geht darum, sie zu finden, bevor jemand mit böser Absicht es tut, und die wichtigsten zu beheben.

Die Kosten eines Sicherheitsaudits werden in Tausenden gemessen. Die Kosten eines Vorfalls werden in Millionen gemessen — ohne das Vertrauen zu zählen, das Sie verlieren.

---

Möchten Sie wissen, wo Ihre Anwendung steht? Sicherheitsbewertung starten →