OWASP ZAP erklärt: was es scannt und die 10 häufigsten Warnungen

OWASP ZAP ist ein kostenloser Open-Source-Scanner, der eine Website so ansieht wie das erste Werkzeug eines Angreifers. Er durchstöbert die Seite, liest jede Antwort und meldet, was falsch aussieht: einen fehlenden Sicherheits-Header, ein Cookie ohne Flag, ein Formular ohne Token. Dies ist eine Erklärung des Werkzeugs; was Kasandros eigene Baseline-Scans zeigten, steht im Beitrag zu unseren Prüfungen.

OWASP ZAP in einem Absatz

ZAP (Zed Attack Proxy) beschreibt die Projektseite als kostenlos und quelloffen und als „den weltweit am häufigsten genutzten Webanwendungs-Scanner“. Es sitzt als Proxy zwischen Browser und Website oder durchsucht die Seite selbst und löst Alerts aus, jeder mit ID und Namen aus dem öffentlichen Katalog. Die Seite trägt die Marke „ZAP by Checkmarx“ und nennt ZAP zugleich ein unabhängiges Open-Source-Projekt. Man startet es als Desktop-App, in Docker oder als Schritt in der CI.

Baseline-Scan und aktiver Scan

Der Baseline-Scan ist der leichte. Laut Dokumentation lässt er standardmäßig eine Minute den Spider laufen, wartet das Ende des passiven Scans ab und berichtet. Er führt „keine echten Angriffe“ aus: Er liest nur die Antworten, die die Website ohnehin gibt, ist also auf der eigenen Seite sicher, dauert wenige Minuten und passt in eine Pipeline. Standardmäßig ist jeder Alert eine Warnung; eine Regeldatei macht aus einer Regel IGNORE, INFO oder FAIL.

Ein aktiver Scan schickt angriffsähnliche Anfragen (zum Beispiel SQL-Injection- oder Reflected-XSS-Payloads). Er kann Daten verändern, gehört also auf eine Testkopie und nur auf ein System, das man testen darf.

Die 10 Warnungen, die man am häufigsten sieht

Diese zehn Alerts bekommen gewöhnliche Websites im Baseline-Scan am häufigsten. IDs und Namen stammen aus dem ZAP-Katalog.

1. Content Security Policy (CSP) Header Not Set (10038). Die Seite sagt dem Browser nicht, welche Skripte und Bilder er laden darf; ein eingeschleustes Skript hat es leichter. Korrektur: ein Content-Security-Policy-Header mit den wirklich genutzten Quellen.
2. Missing Anti-clickjacking Header (10020). Eine fremde Seite könnte Ihre in einem unsichtbaren Frame einbetten und einen Klick unterschieben. Korrektur: frame-ancestors in der CSP oder X-Frame-Options.
3. X-Content-Type-Options Header Missing (10021). Der Browser rät womöglich den Dateityp und führt aus, was Text sein sollte. Korrektur: X-Content-Type-Options: nosniff.
4. Strict-Transport-Security Header Not Set (10035). Ein Erstbesuch über einfaches HTTP lässt sich abfangen. Korrektur: Strict-Transport-Security in HTTPS-Antworten.
5. Cookie No HttpOnly Flag (10010). Ein Skript auf der Seite kann das Cookie lesen. Korrektur: HttpOnly auf Sitzungs-Cookies.
6. Cookie without SameSite Attribute (10054). Das Cookie wird bei Anfragen von anderen Seiten mitgeschickt. Korrektur: SameSite auf Lax oder Strict, wo der Ablauf es erlaubt.
7. Server Leaks Version Information via "Server" HTTP Response Header Field (10036). Die genaue Softwareversion hilft, einen bekannten Exploit auszuwählen. Korrektur: die Version nicht senden.
8. Cross-Domain Misconfiguration (10098). Die Seite erlaubt anderen Origins, ihre Antworten weiter zu lesen als nötig. Korrektur: vertrauenswürdige Origins nennen statt eines Platzhalters.
9. Absence of Anti-CSRF Tokens (10202). Eine andere Seite kann ein Formular im Namen eines angemeldeten Nutzers absenden. Korrektur: ein Token pro Formular oder eine strenge Cookie-Politik plus Origin-Prüfung.
10. Vulnerable JS Library (10003). Eine eingebundene Bibliothek hat eine bekannte Schwachstelle. Korrektur: aktualisieren; eine Abhängigkeitsprüfung in der CI findet es früher.

Zwei weitere begegnen Ihnen im aktiven Scan: SQL Injection (40018) und Cross Site Scripting (Reflected) (40012).

Was ein sauberer Scan nicht beweist

Ein Baseline-Scan liest Antworten; er meldet sich nicht an, versteht Ihre Geldlogik nicht und sucht keine gebrochene Zugriffsregel zwischen zwei Nutzern. Ein sauberes Ergebnis heißt „kein bekannter Header- oder Cookie-Fehler auf den Seiten, die der Spider erreicht hat“. Es ist eine Untergrenze, kein Zertifikat, und ersetzt weder eine Codeprüfung noch einen Penetrationstest durch einen Menschen.

Wie das in der veinito-Gruppe aussieht

ClassKasa, ein Schwesterprodukt der veinito-Gruppe, hat einen OWASP-ZAP-Baseline-Job in seiner CI-Pipeline, und seit dem 13. Oktober 2026 führt Kasandro denselben Baseline-Scan bei jeder Codeänderung aus: Neue Funde stoppen den Build. Der erste Lauf, 63 Prüfungen bestanden und 0 durchgefallen, ist in unserem Beitrag zu den Prüfungen beschrieben.

FAQ

Ist OWASP ZAP kostenlos?

Ja. Die Projektseite beschreibt es als kostenlos und quelloffen.

Ist ein ZAP-Baseline-Scan auf der eigenen Website sicher?

Die Dokumentation sagt, der Baseline-Scan führe keine Angriffe aus; er durchsucht die Seite und analysiert Antworten passiv. Führen Sie ihn auf Systemen aus, die Ihnen gehören oder die Sie testen dürfen.

Heißt ein sauberer ZAP-Scan, dass eine Website sicher ist?

Nein. Er heißt, dass ZAP auf den erreichten Seiten keine bekannten Header-, Cookie- oder Bibliotheksprobleme fand. Logik- und Zugriffsfehler brauchen eine Prüfung durch einen Menschen.

Wurde Kasandro mit ZAP gescannt?

Ja: Der Baseline-Scan läuft seit dem 13. Oktober 2026 bei jeder Codeänderung, und neue Funde stoppen den Build. Der erste Lauf steht in unserem Beitrag zu den Prüfungen.