Umwandlung von HAR-Traffic eines Playwright in Sicherheitsbefunde mit einem MCP-Scanner

QA-Engineer kümmern sich täglich um APIs, HTTP-Anfragen, Anmeldeprozesse, Browserautomatisierung, CI/CD-Pipelines sowie das Verhalten von Anwendungen. Dies überschneidet sich stark mit der Anwendungsicherheit, was die Frage aufwirft: Könnte der von automatisierten Tests erzeugte Traffic bereits als Eingang für Sicherheitstests dienen?

Eine Antwort ist ein MCP (Model Context Protocol)-Server, der den aufgezeichneten Testtraffic auf Sicherheitsprobleme überprüft. Der Ablauf ist einfach: Führen Sie die QA-Automatisierung durch, erfassen Sie den HTTP-Traffic, scannen Sie diesen auf Probleme und lassen Sie eine KI bei der Interpretation der Ergebnisse helfen. Besonders hervorzuheben ist, dass der Scanner niemals zusätzliche Anfragen an die Anwendung sendet.

Zwei Welten teilen sich eine Datenquelle

Sicherheit und Qualitätskontrolle werden in der Regel als getrennte Aktivitäten betrachtet. Die Qualitätskontrollroutine umfasst das Schreiben von Tests, das Ausführen von Tests, die Überprüfung der Funktionalität sowie die Erstellung von Berichten. Die Sicherheitsarbeit findet an anderer Stelle statt: Es werden Sicherheitswerkzeuge eingesetzt, die Anwendung gescannt, Schwachstellen untersucht und die Ergebnisse gemeldet.

Doch automatisierte Tests kommunizieren bereits mit der Anwendung. Sie rufen APIs auf, senden Authentifizierungs-Header und Cookies, erhalten Antworten und kontaktieren Endpunkte. All das ist HTTP-Verkehr, der als Quelle für Sicherheitssignale dienen kann.

HAR-Dateien als Brücke

Werkzeuge wie Playwright können die Netzwerkaktivitäten des Browsers als HAR (HTTP Archive)-Datei speichern. Jede HTTP-Transaktion enthält dabei Details wie:

• Anfragen-URLs und HTTP-Methoden
• Anfragen- und Antwort-Header
• Cookies
• Anfragen- und Antwortkörper
• Statuscodes und weitere Metadaten

Dies ergibt ein Pipeline, das mit der QA-Automatisierung beginnt und mit dem Scannen des dadurch erzeugten Traffics endet:

QA Automation
      │
      ▼
HTTP Traffic
      │
      ▼
    HAR File
      │
      ▼
Security Scanner
      │
      ▼
Security Findings

Es wird keine neue Datenmenge erzeugt. Der Scanner analysiert das, was die Tests bereits erfasst haben, wodurch der Ansatz passiv ist.

Architektur

Der Scanner ist ein TypeScript-Tool, das HAR-Dateien liest und sicherheitsrelevante Signale sucht. Seine Struktur ist absichtlich schlicht gehalten:

Playwright
                        │
                        ▼
                 Network Traffic
                        │
                        ▼
                     HAR File
                        │
                        ▼
                   HAR Parser
                        │
                        ▼
              Normalized Transactions
                        │
                        ▼
                 Security Rules
                   │         │
                   ▼         ▼
                MCP Tool   CLI Gate
                   │         │
                   ▼         ▼
                 AI        CI/CD

Eine wichtige Entscheidung bei der Gestaltung war es, den HAR Parser, ein normalisiertes Transaktionsmodell, die Sicherheitsregeln sowie den Scann-Engine in getrennte Teile aufzuteilen. Nur der Parser kümmert sich um das HAR-Format. Die Regeln sehen niemals die ursprüngliche HAR-Struktur und arbeiten stattdessen mit normalisierten Transaktionen, wodurch das Hinzufügen neuer Regeln später einfach ist.

Überprüfungen in der ersten Version

Fehlender HSTS. Der Scanner markiert Antworten, die diesen Header nicht enthalten:

Strict-Transport-Security

HSTS zwingt Browser dazu, HTTPS zu verwenden, und ist ein wesentlicher Bestandteil einer sicheren Konfiguration.

Einfaches HTTP. Anfragen, die über

http://

anstatt

https://

Zeigt auf versehentlich unsichere Endpunkte, die während normaler Testläufe auftauchen.

Cookie-Attribute. Cookies werden auf Schutzflaggen überprüft:

Secure
HttpOnly
SameSite

Ein Authentifizierungs- oder Sitzungskuchen, der die richtigen Attribute fehlt, verdient eine Überprüfung.

Geheimnisartige Werte in den Antworten. Stellen Sie sich eine Antwort wie folgt vor:

{
  "apiKey": "..."
}

Ein als Zertifikat aussehender Wert, der an einen Client zurückgegeben wird, stellt ein potenzielles Problem dar. Besonders interessant ist dabei, dass ein QA-Test darauf natürlicherweise stoßen kann, ohne dass dazu ein speziell entwickelter Sicherheitstest vorhanden ist.

Empfindliche URL-Parameter. Manchmal landen Geheimnisse in URLs:

/api/user?token=...

Der Scanner überprüft URLs auf Parameternamen und Muster, die als sensibel erscheinen. URLs landen in Protokollen, im Browserverlauf, bei Proxys, in Analyse-Systemen und an anderen Orten – daher ist das wichtig.

Kreditkartennummern. Das gehörte zu den interessanteren Regeln. Der Scanner erkennt Werte, die wie Kartennummern aussehen, und prüft sie mit dem Luhn-Algorithmus. Eine zufällige 16-stellige Zahl sagt wenig aus, doch ein Wert, der einer Kartennummer ähnelt und die Luhn-Prüfung besteht, ist ein stärkeres Zeichen dafür, dass Zahlungsdaten möglicherweise preisgegeben wurden. Die Regel kombiniert Mustererkennung mit echter Validierung.

Gefährliche CORS-Einstellungen. Der Scanner sucht nach gefährlichen Kombinationen. Ein Wildcard-Origin:

Access-Control-Allow-Origin: *

Zusammen mit den erlaubten Anmeldeinformationen:

Access-Control-Allow-Credentials: true

Es rechtfertigt eine Untersuchung. Zudem werden Server erfasst, die den Origin-Wert der Anfrage ohne angemessene Überprüfung einfach zurückgeben.

Den Scanner für KI zugänglich machen

Das Model Context Protocol ist eine Standardmethode dafür, dass KI-Anwendungen externe Tools und Daten nutzen können. Anstatt auf einen eigenständigen Scanner zu beschränken, stellt das Projekt ihn als von KI aufrufbares Tool zur Verfügung. Der MCP-Server stellt ein solches Tool bereit:

secscan_scan_har

Ein AI-Client liefert eine HAR-Datei, führt den Scanner aus und erhält strukturierte Ergebnisse zurück. Der Ablauf sieht so aus:

HAR File
                 │
                 ▼
            MCP Server
                 │
                 ▼
          Security Scanner
                 │
                 ▼
          Security Findings
                 │
                 ▼
            AI Client
                 │
                 ▼
        Explain / Investigate

Das Zeilen für Zeile Lesen eines Berichts ist nicht mehr die einzige Option, denn man kann einfach Fragen zu den Ergebnissen stellen. Typische Fragen wären, welche Erkenntnisse in Bezug auf die Schwere am höchsten eingestuft werden, was mit der Authentifizierung zusammenhängt oder warum eine bestimmte CORS-Einstellung riskant ist. Der Scanner liefert die Beweise, und die KI hilft dabei, sie zu erklären.

KI aus der Bestehen/Fehlschlagen-Entscheidung heraushalten

KI ist gut darin, Erkenntnisse zu erklären, Ergebnisse zusammenzufassen, bei der Untersuchung von Beweisen zu helfen, Lösungen vorzuschlagen und Fragen zu einem Scan zu beantworten. Eine Produktivumsetzung sollte jedoch nicht davon abhängen, ob ein Modell glaubt, dass etwas anfällig ist. Deshalb verfügt das Projekt auch über ein deterministisches CLI-Sicherheitstor:

npm run gate -- test-results/network.har

Wenn kritische Befunde auftreten, kann der Scanner den Build fehlschlagen. Dadurch ergeben sich zwei separate Ansätze. Der erste ist die von KI unterstützte Analyse:

AI-Assisted Analysis

HAR
 ↓
MCP
 ↓
AI
 ↓
Explain / Investigate / Triage

Der zweite ist ein deterministisches Sicherheitstor:

Deterministic Security Gate

HAR
 ↓
Scanner
 ↓
Critical Finding?
 ↓
FAIL BUILD

Die Aufteilung ist wichtig. Verwenden Sie KI dort, wo Schlussfolgerungen und Interaktionen Wert schaffen, und verwenden Sie deterministische Regeln, wo Entscheidungen über Erfolg oder Misserfolg vorhersehbar sein müssen.

Einfügen in einen Playwright-Pipeline

Betrachten Sie einen bestehenden Playwright-CI-Job mit seinem üblichen Testschritt:

- name: Run Playwright tests
  run: npx playwright test

Fügen Sie direkt danach einen Sicherheitsschritt hinzu:

- name: Security Gate
  run: npm run gate -- test-results/network.har

Die gleichen QA-Tests liefern nun zwei Arten von Beweisen: funktionale und Sicherheitsbeweise. Der gesamte Arbeitsablauf sieht dann so aus:

Code
 │
 ▼
Build
 │
 ▼
Playwright Tests
 │
 ▼
Capture HAR
 │
 ▼
Passive Security Scan
 │
 ▼
Security Gate
 │
 ▼
Deploy

Das ist der attraktivste Aspekt dieser Idee. Ein separates Sicherheitsworkflow ist nicht immer für jedes grundlegende Signal notwendig, da einige Überprüfungen natürlich innerhalb des bestehenden QA-Pipelines durchgeführt werden können.

Die schwierige Designfrage

Der Aufbau des MCP-Servers war nicht der schwierige Teil – entscheidend war vielmehr die Strukturierung der Daten zwischen dem HAR-Parser und den Sicherheitsregeln. HAR ist ein detailliertes Format, und wenn jede Regel es direkt verstehen muss, wird die Wartung schnell schwierig. Eine Zwischenrepräsentation löst dieses Problem:

HAR
 │
 ▼
Parser
 │
 ▼
Transaction
 │
 ▼
Security Rules

Die Regeln kümmern sich nicht darum, wo eine Transaktion entstanden ist. Sie erhalten etwas, das sie bereits verstehen, was die Erweiterung des Scanners erleichtert.

Was könnte als Nächstes kommen

Es handelt sich um eine erste Version, bei der noch viel Raum für Weiterentwicklung besteht. Zu den Überprüfungen gehören:

• Analysierung der Content Security Policy
• X-Content-Type-Options und Referrer-Policy
• Probleme mit Cache-Control
• Offenlegung von JWTs
• Schwächen in der Authentifizierung und Sitzung
• Offenlegung sensibler Daten
• Mehr CORS-Überprüfungen
• Signale im Zusammenhang mit der Autorisierung

Die Ergebnisse können auch um detailliertere Belege erweitert werden, wie folgt gestaltet:

Finding
Severity
Rule
Evidence
Request
Response
Impact
Remediation

Die MCP-Schicht könnte irgendwann Fragen wie „Welche Befunde sollten zuerst untersucht werden?“, „Sind mehrere Befunde auf dasselbe Konfigurationsproblem zurückzuführen?“ und „Erklären Sie diesen Befund einem Entwickler.“ beantworten.

Eine weitere Richtung ist die Integration in CI-Prozesse: GitHub Actions, Sicherheitskommentare zu Pull Requests, SARIF-Ausgaben, Schweregradsschwellenwerte, Baseline-Befunde sowie die Erkennung von Sicherheitsrückfällen. Das Ziel ist es, dass Sicherheitstests wie eine weitere Qualitätskontrolle wirken und nicht wie eine separate Sache behandelt werden.

Warum QA-Mitarbeiter gut geeignet sind

Ein Großteil der täglichen Arbeit von QA-Engineern ist auch grundlegend für die Anwendungsicherheit: HTTP, APIs, Authentifizierung und Autorisierung, Testautomatisierung, CI/CD, Verhaltens- und Fehleranalyse von Anwendungen. Die Entwicklung eines Tools vertieft das Verständnis mehr als allein Kurse oder Zertifikate. Ein solches Projekt behandelt nacheinander HAR-Parsing, HTTP-Sicherheit, Cookies, CORS, die Erkennung geheimer und sensibler Daten, Sicherheitsregeln, MCP, CLI-Gates sowie CI/CD.

Der Nutzen geht über ein weiteres Repository hinaus: Es zeigt, wie QA-Automatisierungsdaten in Sicherheitsintelligenz umgewandelt werden können. Tests überwachen bereits das Verhalten der Anwendungen, HAR-Dateien erfassen dieses in strukturierter Form, Regeln extrahieren nützliche Signale aus dem Datenverkehr und MCP ermöglicht es KI-Clienten, auf diese Fähigkeiten zuzugreifen. Zusammen bilden sie eine einheitliche Konzeption:

QA Automation
      +
Application Security
      +
AI
      +
DevSecOps

Der wesentliche Punkt ist, dass Sicherheitstests nicht unbedingt mit einem weiteren Scan beginnen müssen. Sie können mit den bereits durchgeführten Traffic-Tests starten. Die Kombination aus QA-Automatisierung, Anwendungssecurity, KI und DevSecOps verspricht mehr Erfolge und deckt ein breiteres Spektrum ab als jede dieser Methoden für sich allein.