Ein kostenloser Scanner, der das SSL-Zertifikat und die HTTP-Header überprüft, erweckt einen falschen Eindruck von Abdeckung. Die OWASP Top 10:2025 platziert Security Misconfiguration auf dem zweiten Platz und führt Software Supply Chain Failures als eigenständige Kategorie ein. Die Sicherheit einer Website online zu testen, setzt voraus, dass man versteht, was diese Tools tatsächlich erfassen und vor allem, was sie ignorieren.
Supply Chain und außergewöhnliche Bedingungen: die blinden Flecken kostenloser Scanner
Die meisten ohne Anmeldung zugänglichen Tools analysieren die exponierte Oberfläche: Gültigkeit des TLS-Zertifikats, Vorhandensein der Header Content-Security-Policy, X-Frame-Options, DNS-Konfiguration. Das ist eine nützliche Grundlage, die jedoch weder die Software-Abhängigkeitenskette noch das Management von Anwendungsfehlern abdeckt.
Die OWASP Top 10:2025 hat diese beiden Risiken unter den Kategorien Software Supply Chain Failures und Mishandling of Exceptional Conditions formalisiert. Eine über npm importierte JavaScript-Komponente, ein Docker-Image, das auf einer nicht gewarteten Basis aufgebaut ist, ein CI/CD-Pipeline, deren Geheimnisse offengelegt sind: Kein anonymer externer Scan erkennt diese Mängel.
Wir empfehlen, den Online-Scan als ersten Filter zu betrachten, nicht als Audit. Er identifiziert die von außen sichtbaren Konfigurationsfehler. Für die Software-Kette ist ein Tool vom Typ Software Composition Analysis (Snyk Open Source, OWASP Dependency-Check) erforderlich, das im Code-Repository ausgeführt wird.
Bevor Sie einen Scan starten, ist es hilfreich, die Sicherheit einer Website online zu testen, indem Sie genau verstehen, welcher Umfang von jedem Tool abgedeckt wird, um zu vermeiden, einen sauberen Bericht mit einer tatsächlich reduzierten Angriffsfläche zu verwechseln.
Security Misconfiguration: was die HTTP-Header-Scans wirklich erkennen
Der Anstieg von Security Misconfiguration auf den zweiten Platz im OWASP-Ranking ist nicht anekdotisch. Er spiegelt die Zunahme der Konfigurationsoberflächen wider: öffentliche Cloud-Buckets, zugängliche Verwaltungsendpunkte, ausführliche Fehlermeldungsseiten, die Stack-Traces offenlegen, Cookies ohne das Attribut Secure oder SameSite.
Die kostenlosen Scanner decken einen Teil dieses Umfangs ab. Sie überprüfen typischerweise:
- Das Vorhandensein und den Wert der HTTP-Sicherheitsheader (Strict-Transport-Security, X-Content-Type-Options, Referrer-Policy, Permissions-Policy)
- Die TLS-Konfiguration (Protokollversion, Verschlüsselungs-Suites, Ablauf des Zertifikats)
- Die Offenlegung von Serverinformationen in den Antwort-Headern (Server, X-Powered-By)
- Die CORS-Policy und die erlaubten Ursprünge
Im Gegensatz dazu testet ein externer Scan nicht die internen Konfigurationen: IAM-Regeln eines S3-Buckets, Zugriff auf eine durch eine obskure URL geschützte Administrationskonsole oder Umgebungsvariablen, die im Klartext im Client-Seiten-Quellcode injiziert sind. Diese Überprüfungen erfordern einen authentifizierten Zugriff oder ein Audit des bereitgestellten Codes.
Ein Sicherheitsbewertung interpretieren, ohne sie zu überschätzen
Ein Bericht, der eine hohe Punktzahl (A oder A+) bei den HTTP-Headern anzeigt, bedeutet nicht, dass die Anwendung sicher ist. Es bedeutet, dass die Transportschicht und die Browsereinstellungen korrekt konfiguriert sind. Wir beobachten regelmäßig Websites, die mit A+ bewertet werden, deren Administrationspanel über /admin ohne IP-Beschränkung oder Zwei-Faktor-Authentifizierung zugänglich ist.
Die Punktzahl ist ein Indikator für die Reife in einem bestimmten Umfang. Sie deckt weder die Geschäftslogik noch die Anwendungszugangskontrollen ab.
Broken Access Control und authentifizierte Tests: die strukturelle Grenze des anonymen Scans
Das Risiko, das 2025 von OWASP als Nummer eins eingestuft wird, bleibt Broken Access Control, das nun auch SSRF (Server-Side Request Forgery) umfasst. Diese Art von Schwachstelle erfordert Testkonten mit mehreren Berechtigungsstufen und konkreten Geschäftsszenarien: ein Standardbenutzer, der versucht, auf eine Ressource zuzugreifen, die einem Administrator vorbehalten ist, eine API-Anfrage, die die ID eines Objekts ändert, um die Daten eines anderen Benutzers zu erreichen (IDOR).
Kein anonymer externer Scanner kann die Zugangskontrollen validieren, ohne mindestens zwei authentifizierte Sitzungen mit unterschiedlichen Rollen zu haben. Ein Tool wie OWASP ZAP ermöglicht es, Authentifizierungskontexte zu konfigurieren und Szenarien nachzuspielen, aber das geht über den Rahmen eines einfachen Online-Tests hinaus.
Kombinierter Ansatz für ein realistisches Audit ohne Budget
Um einen akzeptablen Umfang ohne finanzielle Investition abzudecken, empfehlen wir, drei Schichten zu kombinieren:
- Ein Scan der Header und der TLS-Konfiguration über ein kostenloses Online-Tool (Mozilla Observatory, SecurityHeaders.com) für den Netzwerk- und Transportumfang
- Ein lokaler Interception-Proxy (OWASP ZAP im Standardmodus), um manuell die Zugangskontrollen und Injektionen in Formularen mit authentifizierten Sitzungen zu testen
- Eine Abhängigkeitsanalyse (npm audit, pip-audit, OWASP Dependency-Check) direkt im Build-Pipeline, um die Software-Kette abzudecken
Diese Kombination deckt drei der fünf größten Risiken im OWASP-Ranking 2025 ab. Sie ersetzt kein professionelles Pentest, erhöht jedoch signifikant das Erkennungsniveau im Vergleich zu einem einzelnen HTTP-Header-Scan.
CORS, Cookies und Content-Security-Policy: die Einstellungen, die vorrangig überprüft werden sollten
Unter den kostenlos testbaren Elementen konzentrieren sich drei Konfigurationen auf einen unverhältnismäßig hohen Anteil an ausnutzbaren Fehlern.
Die falsch konfigurierte CORS-Policy bleibt häufig. Ein Access-Control-Allow-Origin, der auf * gesetzt ist, mit Access-Control-Allow-Credentials auf true, exponiert die Sitzungscookies für jede Drittanbieter-Domain. Die kostenlosen Scanner melden diese Kombination, testen jedoch nicht die anwendungsseitigen Konsequenzen.
Die Cookie-Attribute verdienen besondere Aufmerksamkeit. Ein Sitzungscookie ohne Secure, ohne HttpOnly und ohne SameSite=Strict (oder Lax) ist anfällig für Diebstahl über XSS oder für die Einbeziehung in Cross-Site-Anfragen. Neuere Browser mildern einige Szenarien, aber die explizite Konfiguration bleibt der einzige zuverlässige Schutz auf der Serverseite.
Schließlich macht eine permissive Content-Security-Policy den Schutz gegen XSS-Injektionen zunichte. Eine script-src-Direktive, die ‘unsafe-inline’ oder ‘unsafe-eval’ enthält, macht die CSP kosmetisch. Die Online-Scan-Tools erkennen diese Direktiven, was sie zu einer der wenigen anwendungsseitigen Kontrollen macht, die ohne Authentifizierung zugänglich sind.
Die Kostenfreiheit eines Testtools stellt an sich kein Problem dar. Was ein falsches Sicherheitsgefühl erzeugt, ist die Behandlung des Berichts als umfassend, während er nur einen Bruchteil der tatsächlichen Angriffsfläche abdeckt. Ein sauberer Scan der HTTP-Header bleibt ein guter Ausgangspunkt, vorausgesetzt, man folgt mit den Schichten, die das Tool nicht erreichen kann.
