Playwright über OWASP ZAP routen: Ein CI/CD-Runbook für kontinuierliches DAST

Jährliche Penetrationstests decken kritische Schwachstellen oft erst Monate nachdem der fehlerhafte Code in Produktion gegangen ist auf. Für Teams, die Continuous-Delivery-Pipelines betreiben, ist eine Sicherheitsüberprüfung, die lediglich ein- oder zweimal pro Jahr stattfindet, praktisch obsolet, noch bevor der PDF-Bericht im Posteingang des Managements landet. Gleichzeitig stoßen herkömmliche DAST-Crawler (Dynamic Application Security Testing) bei modernen Webanwendungen an ihre Grenzen: Sie scheitern an komplexen mehrstufigen State Machines, straucheln beim clientseitigen Routing und können moderne Single-Sign-On- (SSO) oder Multi-Faktor-Authentifizierungsbarrieren nicht überwinden.

Ihre Quality-Assurance-Pipeline enthält jedoch bereits die exakte Lösung für dieses Transparenzproblem: Ihre Playwright-End-to-End-Regressionssuite (E2E) durchläuft bereits komplexe Geschäftsprozesse, authentifiziert sich über Edge Cases hinweg, füllt Formulare mit validen Daten aus und erreicht tief verschachtelte Views, die Headless-Spider schlicht übersehen.

Indem Sie den Traffic von Playwright über OWASP ZAP (Zed Attack Proxy) als vorgeschalteten Intercepting Proxy leiten, verwandeln Sie alltägliche Funktionstests in ein kontinuierliches, automatisiertes Sicherheitsaudit. Hier ist das operative Runbook für die Implementierung dieser Architektur in Ihrer Continuous-Integration-Pipeline (CI).

Das Spider-Problem: Warum traditionelles DAST an modernen SPAs scheitert

Eigenständige DAST-Tools verlassen sich stark auf Crawler, um Angriffsoberflächen zu identifizieren. Herkömmliche Spider folgen einfachen HTML-Hyperlinks und senden auffindbare <form>-Tags ab. In einer klassischen Multi-Page-Architektur bildete dieser Ansatz einen soliden Teil des Anwendungsumfangs ab.

Moderne Single-Page-Applications (auf Basis von React, Vue, Angular oder Svelte) hebeln traditionelle Crawler jedoch vollständig aus:

• Die Navigation erfolgt über JavaScript-History-Manipulationen statt über serverseitig gerenderte Hyperlinks.
• Zustandsübergänge hängen von asynchronen REST- oder GraphQL-Payloads ab.
• Interaktive Komponenten erfordern präzise Abfolgen von Benutzerinteraktionen (z. B. das Klicken auf einen Toggle, das Öffnen eines Modals, das Bestätigen einer Aktion), bevor die eigentlichen Endpunkte überhaupt aufgerufen werden.
• Authentifizierungs-Token liegen im Session Storage, im Arbeitsspeicher oder in HTTP-only-Cookies, die Spider nicht zuverlässig verarbeiten können.

Versucht ein eigenständiger Scanner, ein modernes SaaS-Dashboard zu crawlen, deckt er routinemäßig weniger als 20 % des Routing-Baums ab, bevor er in Endlosschleifen gerät oder wieder auf der Login-Maske landet.

Im Gegensatz dazu ist die Playwright-Suite eines Entwicklerteams genau darauf ausgelegt, legitimes Benutzerverhalten zu simulieren. Sie weiß, wie man sich anmeldet, Banner schließt, mit benutzerdefinierten UI-Widgets interagiert und Backend-API-Aufrufe auslöst. Wenn Playwright den Browser steuert, während OWASP ZAP im Hintergrund zuhört, erhält ZAP eine vollständige, vorauthentifizierte Sitemap, ohne dass ein autonomer Crawler mühsam den Weg erraten muss.

Architektur-Blueprint: Das Intercepting-Proxy-Pattern

Die Integration gliedert sich in drei unterschiedliche Phasen innerhalb der Delivery-Pipeline:

1. Initialisierung des Proxy-Daemons: OWASP ZAP startet im Daemon-Modus innerhalb eines Containers und stellt einen HTTP-Proxy-Port (üblicherweise 8080 oder 8090) sowie einen administrativen API-Port bereit.
2. Proxy-gestützte Testausführung (Passives Scanning): Playwright startet Headless-Browser-Kontexte, die so konfiguriert sind, dass der gesamte HTTP/HTTPS-Traffic über den ZAP-Proxy geleitet wird. Während Playwright seine funktionalen Regressionstests ausführt, zeichnet ZAP jede Anfrage und Antwort auf und analysiert passiv Header, Cookies, Anti-CSRF-Token sowie DOM-Inhalte auf Sicherheitslücken, ohne Payloads zu modifizieren.
3. Gezieltes aktives Scanning (Angriffssimulation): Sobald die Playwright-Suite abgeschlossen ist, stößt die CI-Pipeline einen aktiven Scan auf die exakten URLs, Parameter und Endpunkte an, die in ZAPs Sitzungshistorie erfasst wurden. ZAP injiziert gezielte Sicherheits-Testvektoren (SQL-Injection, Cross-Site Scripting, Path Traversal, Header-Manipulation) in reale, nachweislich existierende Anwendungspfade.

+-------------------------------------------------------------+
| CI/CD-Pipeline Container-Umgebung                           |
|                                                             |
|  +--------------------+        HTTP/S-Proxy        +-----+  |
|  | Playwright Runner  | -------------------------> |     |  |
|  | (E2E-Testsuite)    |                            |  Z  |  |
|  +--------------------+                            |  A  |  |
|            |                                       |  P  |  |
|            | Steuert UI                            |     |  |
|            v                                       |     |  |
|  +--------------------+    Zielanwendung           |  P  |  |
|  | Headless Chromium- | -------------------------> |  r  |  |
|  | Kontext            |   (über ZAP-Proxy-Host)    |  o  |  |
|  +--------------------+                            |  x  |  |
|                                                    |  y  |  |
|  +--------------------+        Scan-Steuerung      |     |  |
|  | Pipeline-Skript /  | -------------------------> |     |  |
|  | ZAP REST Client    |   (Aktiven Scan auslösen)  |     |  |
|  +--------------------+                            +-----+  |
+-------------------------------------------------------------+

Diese entkoppelte Architektur ermöglicht es Teams, ihre funktionalen Tests beizubehalten, ohne die Testlogik mit Sicherheitsprüfungen zu überfrachten, während Sicherheitsteams kontinuierliche Einblicke in reale User Journeys erhalten.

Schritt-für-Schritt-Implementierung

Die Einrichtung von OWASP ZAP Playwright Automated Security Testing erfordert die Konfiguration des Container-Netzwerks, das Verwalten von TLS-Vertrauensstellungen, die Konfiguration der Playwright-Browser-Kontexte und die Orchestrierung von ZAP über dessen REST-API.

Schritt 1: OWASP ZAP in der CI bereitstellen

Starten Sie das offizielle OWASP ZAP Docker-Image im Daemon-Modus auf einem Enterprise-CI/CD-Runner (wie GitHub Actions, GitLab CI oder einer lokalen Docker Compose-Testumgebung). Stellen Sie sicher, dass der API-Schlüssel sicher übergeben oder für private Runner-Netzwerke explizit deaktiviert wird.

Das folgende docker-compose.yml-Snippet zeigt eine isolierte Testumgebung:

version: "3.8"

services:
  zap:
    image: ghcr.io/zaproxy/zaproxy:stable
    command: zap.sh -daemon -host 0.0.0.0 -port 8080 -config api.disablekey=true -config api.addrs.addr.name=.* -config api.addrs.addr.regex=true
    ports:
      - "8080:8080"
    volumes:
      - ./zap-reports:/zap/wrk:rw

  app-under-test:
    build:
      context: .
      dockerfile: Dockerfile.app
    ports:
      - "3000:3000"
    environment:
      - NODE_ENV=test
      - DATABASE_URL=postgres://test:test@db:5432/test_db

Schritt 2: Playwright für das Traffic-Routing über den Proxy konfigurieren

Standardmäßig lehnen moderne Browser-Engines selbstsignierte Zertifikate ab, die von Intercepting Proxies generiert werden. Wenn Playwright HTTPS-Traffic durch ZAP tunnelt, verschlüsselt ZAP die Verbindung mit seiner internen Root Certificate Authority (CA) neu.

Sie müssen Playwright explizit anweisen, den Datenverkehr über den Proxy zu leiten und die Zertifikatsprüfung zu handhaben. Sie können entweder die ZAP-Root-CA in den Zertifikatsspeicher des Betriebssystems importieren oder die Playwright-Einstellung ignoreHTTPSErrors innerhalb einer isolierten CI-Sandbox konfigurieren.

Hier ist eine praxiserprobte Playwright-Konfiguration (playwright.config.ts), die die Proxy-Integration herstellt:

import { defineConfig, devices } from '@playwright/test';

const ZAP_PROXY_HOST = process.env.ZAP_PROXY_HOST || '127.0.0.1';
const ZAP_PROXY_PORT = process.env.ZAP_PROXY_PORT || '8080';
const USE_SECURITY_PROXY = process.env.ENABLE_SECURITY_PROXY === 'true';

export default defineConfig({
  testDir: './e2e',
  timeout: 60000,
  retries: 0, // Retries can distort passive scan logs
  use: {
    baseURL: process.env.APP_URL || 'http://localhost:3000',
    trace: 'retain-on-failure',
    // Route traffic through ZAP when the security flag is active
    ...(USE_SECURITY_PROXY && {
      proxy: {
        server: `http://${ZAP_PROXY_HOST}:${ZAP_PROXY_PORT}`,
      },
      // ZAP dynamically re-signs HTTPS traffic
      ignoreHTTPSErrors: true,
    }),
  },
  projects: [
    {
      name: 'chromium-security',
      use: { 
        ...devices['Desktop Chrome'],
        launchOptions: {
          args: [
            // Ensure WebRTC and non-proxied subchannels do not leak
            '--disable-features=IsolateOrigins,site-per-process',
          ],
        },
      },
    },
  ],
});

Schritt 3: Anwendungszustand über Playwright aufbauen

Führen Sie Ihre standardmäßigen Playwright-Funktionstests gegen die Staging-Instanz aus. Die Testsuite durchläuft normale User Journeys:

import { test, expect } from '@playwright/test';

test.describe('Authenticated User Workflows', () => {
  test('User can update security profile parameters', async ({ page }) => {
    // Authenticate
    await page.goto('/login');
    await page.fill('input[name="username"]', '[email protected]');
    await page.fill('input[name="password"]', 'CorrectHorseBatteryStaple99!');
    await page.click('button[type="submit"]');

    // Confirm navigation into dashboard
    await expect(page.locator('h1')).toContainText('Account Overview');

    // Perform state-changing actions
    await page.goto('/settings/profile');
    await page.fill('input[name="displayName"]', 'Auditor Test User');
    await page.fill('input[name="billingEmail"]', '[email protected]');
    await page.click('button#save-profile');

    // Assert successful completion so ZAP logs the full mutation cycle
    await expect(page.locator('.toast-success')).toBeVisible();
  });
});

Jeder HTTP-Request, der während dieser Session ausgelöst wird, einschließlich Authentifizierungs-Cookies, CSRF-Tokens und JSON-Payloads, ist nun im Speicher von ZAP indexiert.

Schritt 4: Schwachstellenanalyse über die ZAP-API automatisieren

Nachdem Playwright die Ausführung beendet hat, führt ein Koordinator-Skript die Abfragen an die REST-API von ZAP aus. Dieses Skript prüft den Fortschritt des passiven Scans, startet einen aktiven Scan gegen die erfassten Endpunkte und erstellt maschinenlesbare Schwachstellenberichte.

Hier ist ein produktionsreifer Node.js-Pipeline-Runner (run-dast-analysis.ts):

import axios from 'axios';
import fs from 'fs';
import path from 'path';

const ZAP_BASE_URL = process.env.ZAP_URL || 'http://127.0.0.1:8080';
const TARGET_URL = process.env.APP_URL || 'http://localhost:3000';

async function sleep(ms: number): Promise<void> {
  return new Promise((resolve) => setTimeout(resolve, ms));
}

async function waitForPassiveScan(): Promise<void> {
  console.log('[DAST] Awaiting passive scan queue clearance...');
  let recordsRemaining = 1;

  while (recordsRemaining > 0) {
    const response = await axios.get(`${ZAP_BASE_URL}/JSON/pscan/view/recordsToScan/`);
    recordsRemaining = parseInt(response.data.recordsToScan, 10);
    if (recordsRemaining > 0) {
      console.log(`[DAST] Records remaining in queue: ${recordsRemaining}`);
      await sleep(2000);
    }
  }
  console.log('[DAST] Passive scanning complete.');
}

async function triggerActiveScan(): Promise<void> {
  console.log(`[DAST] Launching Active Scan against target: ${TARGET_URL}`);
  
  // Exclude administrative logout paths to keep context alive
  await axios.get(`${ZAP_BASE_URL}/JSON/ascan/action/excludeFromScan/`, {
    params: { regex: `${TARGET_URL}/logout.*` },
  });

  const scanInit = await axios.get(`${ZAP_BASE_URL}/JSON/ascan/action/scan/`, {
    params: {
      url: TARGET_URL,
      recurse: true,
      inScopeOnly: false,
    },
  });

  const scanId = scanInit.data.scan;
  let progress = 0;

  while (progress < 100) {
    await sleep(5000);
    const statusResponse = await axios.get(`${ZAP_BASE_URL}/JSON/ascan/view/status/`, {
      params: { scanId },
    });
    progress = parseInt(statusResponse.data.status, 10);
    console.log(`[DAST] Active Scan progress: ${progress}%`);
  }
  console.log('[DAST] Active Scan finalized.');
}

async function generateReports(): Promise<void> {
  console.log('[DAST] Fetching vulnerability alerts...');
  const alertsResponse = await axios.get(`${ZAP_BASE_URL}/JSON/core/view/alerts/`, {
    params: { baseurl: TARGET_URL },
  });

  const alerts = alertsResponse.data.alerts;
  const criticalOrHigh = alerts.filter(
    (a: { risk: string }) => a.risk === 'High' || a.risk === 'Critical'
  );

  const reportHtml = await axios.get(`${ZAP_BASE_URL}/OTHER/core/other/htmlreport/`);
  fs.writeFileSync(path.join(process.cwd(), 'zap-security-report.html'), reportHtml.data);

  console.log(`[DAST] Total alerts detected: ${alerts.length}`);
  console.log(`[DAST] High/Critical alerts detected: ${criticalOrHigh.length}`);

  if (criticalOrHigh.length > 0) {
    console.error('[DAST] Failing build due to security vulnerabilities above severity threshold.');
    process.exit(1);
  }
}

async function main(): Promise<void> {
  try {
    await waitForPassiveScan();
    if (process.env.RUN_ACTIVE_SCAN === 'true') {
      await triggerActiveScan();
    }
    await generateReports();
  } catch (error) {
    console.error('[DAST] Security scan orchestration failed:', error);
    process.exit(1);
  }
}

main();

Risiken aktiver Scans beherrschen: Häufige Fallstricke vermeiden

Aktive Sicherheitsscans beobachten nicht nur passiv; sie attackieren Endpunkte gezielt mit Fuzzing-Techniken. Bei unvorsichtigem Einsatz kann das gravierende Nebenwirkungen auf nachgelagerte Systeme haben.

1. Verschmutzung von Datenbank und Anwendungsstatus

Ein aktiver Scan auf Pfade wie /api/v1/users/delete oder /api/v1/organization/reset führt diese Requests mit variierenden Payload-Injektionen aus. Verarbeitet Ihre Anwendung während eines Scans einen DELETE-Aufruf, werden Testdaten gelöscht, die von nachfolgenden Anfragen noch benötigt werden.

Gegenmaßnahmen:

• Führen Sie aktive Scans ausschließlich gegen ephemere Preview-Umgebungen mit dedizierten Testdatenbanken aus, die unmittelbar nach Abschluss der Pipeline wieder vernichtet werden.
• Konfigurieren Sie ZAP-Scan-Policies so, dass destruktive Pfade ausgeschlossen werden. Nutzen Sie ZAPs Regex-Exclusion-API, um URLs mit Mustern wie /.*delete.*/, /.*logout.*/ oder /.*cancel.*/ zu ignorieren.

2. Session-Invalidierung während der Tests

Trifft der aktive Scanner auf einen Endpunkt wie /api/auth/logout, wird das aufgezeichnete Session-Cookie serverseitig ungültig. Jeder nachfolgende Angriffsversuch von ZAP liefert einen Status 401 Unauthorized zurück, wodurch der restliche Scan nutzlos wird.

Gegenmaßnahmen:

• Richten Sie explizite Ausschlussregeln für Logout-URLs ein, bevor Sie ascan/action/scan aufrufen.
• Konfigurieren Sie alternativ ZAPs Authentication-Context-Engine mit einem Re-Authentifizierungs-Skript, das Sitzungsabbrüche erkennt und Bearer-Tokens oder Cookies automatisch erneuert.

3. CI-Timeouts und lange Scan-Dauern

Playwright-Tests laufen oft in 3 bis 5 Minuten durch. Ein unbeschränkter aktiver Scan, der Tausende von Angriffsvektoren über Hunderte gefundener Endpunkte abfeuert, kann jedoch mehrere Stunden in Anspruch nehmen und CI-Runner blockieren.

Gegenmaßnahmen:

• Fokussierte Scan-Policies: Führen Sie nicht alle Scan-Regeln aus. Erstellen Sie eine angepasste ZAP-Scan-Policy (.policy-Datei), die sich gezielt auf kritische Schwachstellenklassen konzentriert: SQL-Injection, Remote Code Execution, Server-Side Template Injection (SSTI) und Path Traversal. Deaktivieren Sie zeitaufwendige Prüfungen wie brute-force Directory Discovery.
• Trennung von passiven und aktiven Pipelines: Führen Sie passive Scans bei jedem Pull Request aus (verursacht weniger als 30 Sekunden zusätzlichen Overhead). Planen Sie vollständige aktive Scans stattdessen als nächtliche Jobs auf einem dedizierten Staging-Deployment ein.

Bei der Überprüfung komplexer verteilter Anwendungen sollten Teams sicherstellen, dass Testprotokolle Datenflüsse absichern und Audit-Trails wahren, ähnlich wie bei Best Practices für Security in der Software-Lieferkette.

Beispielrechnung: Kosten und Abdeckung im CI/CD-Vergleich

Um die operativen Auswirkungen der ZAP-Playwright-Integration zu veranschaulichen, betrachten wir eine typische mittelgroße B2B-SaaS-Webanwendung mit folgenden Parametern:

Anwendungsumfang:
- 120 eindeutige API-Endpunkte
- 45 interaktive UI-Views
- 85 Playwright-E2E-Testszenarien

Ausführungszeiten:
- Basis-Playwright-E2E-Suite: 4 Minuten, 15 Sekunden
- Overhead der passiven ZAP-Analyse: +25 Sekunden (gesamt ~4m 40s)
- Dauer des zielgerichteten aktiven Scans (Top-4-Kategorien): 14 Minuten, 30 Sekunden

Bei einem Team mit 15 Pull Requests pro Tag bedeutet dies:

• Passives Scanning bei jedem PR verursacht über den gesamten Tag verteilt weniger als 6,5 Minuten zusätzliche Runner-Laufzeit.
• Ein nächtlicher aktiver Scan beansprucht 14,5 Minuten Rechenleistung außerhalb der Stoßzeiten und liefert verifizierte Security-Telemetrie über alle 120 Endpunkte hinweg, ohne manuellen Eingriff.

Der Vergleich mit einem externen Penetrationstest-Zyklus verdeutlicht den Unterschied:

4 Best Practices für CI-integriertes DAST

Die erfolgreiche Implementierung automatisierter Sicherheitsscans erfordert klare Richtlinien, um Entwicklerteams nicht mit Fehlalarmen zu überlasten:

1. Pipelines über SARIF-Exporte mit klaren Schwellenwerten steuern Konfigurieren Sie ZAP so, dass Ergebnisse im SARIF-Format (Static Analysis Results Interchange Format) exportiert werden. Importieren Sie diese direkt in GitHub Security Advisories oder GitLab Vulnerability Management. Setzen Sie strikte Quality Gates: Lassen Sie Builds nur bei Meldungen der Stufen High oder Critical mit Confidence > Medium fehlschlagen, um Pipeline-Blockaden durch spekulative False Positives (wie allgemeine Warnungen zu fehlenden Headern) zu vermeiden.

2. Dynamische Secrets vom Testcode entkoppeln Stellen Sie sicher, dass ZAP-API-Token, Testbenutzer-Credentials und Service-URLs über sichere CI-Environment-Secrets bereitgestellt werden. Hinterlegen Sie niemals statische ZAP-API-Schlüssel in versionierten Playwright-Konfigurationen oder Orchestrierungsskripten.

3. Kontext-Isolierung über unterschiedliche Testrollen hinweg wahren Bedient Ihre Anwendung verschiedene Berechtigungsstufen (z. B. Standard-Mandant vs. Systemadministrator), sollten Sie getrennte Playwright-Kontexte über separate ZAP-Sitzungen laufen lassen. So können Sie überprüfen, ob über manipulierte Parameter aus Sessions mit geringen Rechten auf Endpunkte zugegriffen werden kann, die nur Administratoren vorbehalten sind.

4. ZAP-Policies auf den Tech-Stack der Anwendung abstimmen Läuft Ihre Anwendung ausschließlich auf Node.js und PostgreSQL, deaktivieren Sie in Ihrer ZAP-Policy Regeln für PHP-Code-Injection, ASP.NET-Path-Disclosure oder Oracle-spezifische SQL-Payloads. Das Bereinigen irrelevanter Regelsätze reduziert die Scan-Dauer um bis zu 60 %, ohne die Erkennungsrate für relevante Risiken zu schmälern.

Mehr als nur punktuelle Tests

Entwicklungsteams stehen oft vor der Herausforderung, Feature-Velocity und ein hohes Sicherheitsniveau in Einklang zu bringen. Der Aufbau einer solchen Testorchestrierung verlangt eine präzise Abstimmung zwischen Frontend-Treibern, Container-Netzwerken, Proxy-Engines und Workflows zur Schwachstellenpriorisierung.

Unternehmen, die robuste, produktionsreife Webplattformen entwickeln möchten, ohne interne Produktteams von der Kernentwicklung abzuziehen, setzen hierbei häufig auf spezialisierte Partner. Die Zusammenarbeit mit einem erfahrenen Team für Individualsoftware-Entwicklung stellt sicher, dass Anwendungen vom ersten Tag an mit automatisierter Verifikation, Security Hardening und belastbaren CI/CD-Pipelines aufgebaut werden.

Prüfen Sie Ihre aktuelle Testsuite: Wenn Ihre Playwright-Tests bereits die wesentliche Geschäftslogik abdecken, trennt Sie lediglich eine Proxy-Konfiguration davon, Ihre funktionalen Regressionstests in eine kontinuierliche, automatisierte Penetrationstest-Engine zu verwandeln.

Quelle: Software Testing: ZAP als Proxy: Regressionstests werden zu Sicherheitstests