Scanner Passiv: Anwendung, typische Fehler, Praxiswissen und saubere Workflows

Passives Scanning ist keine harmlose Nebenfunktion, sondern ein permanenter Analyseprozess auf Basis bereits beobachteter Requests und Responses. Der Scanner sendet dabei keine zusätzlichen Prüf-Requests an das Ziel. Stattdessen bewertet er den vorhandenen Traffic auf Muster, Fehlkonfigurationen, unsichere Header, Informationslecks, schwache Cookie-Attribute, reflektierte Eingaben, Caching-Probleme, inkonsistente Content-Typen und viele weitere Hinweise. Genau deshalb ist passives Scanning in produktiven oder sensiblen Umgebungen oft der erste saubere Einstieg: Es erzeugt keine aktive Last und verändert den Anwendungszustand nicht absichtlich.

In der Praxis entsteht der größte Nutzen nicht durch einzelne Findings, sondern durch die Breite der Sichtbarkeit. Sobald Traffic über den Proxy läuft oder aus der Proxy History in den Scanner gelangt, beginnt Burp damit, Antworten systematisch zu bewerten. Das ist besonders wertvoll in frühen Testphasen, wenn noch unklar ist, welche Teile einer Anwendung stabil, kritisch oder besonders sensibel sind. Passive Ergebnisse liefern dann eine erste Landkarte: Welche Hosts setzen keine Security-Header, wo werden interne Pfade offengelegt, welche Cookies sind nicht mit HttpOnly oder Secure versehen, welche Antworten enthalten Versionshinweise oder Debug-Artefakte?

Wichtig ist die Abgrenzung zu Scanner Aktiv. Aktive Prüfungen versuchen Schwachstellen gezielt zu provozieren. Passives Scanning dagegen beobachtet nur. Das bedeutet aber nicht, dass die Ergebnisse automatisch trivial sind. Ein fehlendes SameSite-Attribut, ein offener CORS-Header, ein Stacktrace mit Framework-Version oder ein Cache-Control-Fehler kann in realen Angriffsketten entscheidend sein. Viele erfolgreiche Angriffe beginnen nicht mit einer spektakulären Injection, sondern mit kleinen, sauber korrelierten Hinweisen aus passiver Analyse.

Ein häufiger Denkfehler besteht darin, passives Scanning als vollautomatische Schwachstellenbewertung zu betrachten. Tatsächlich liefert es vor allem technische Indikatoren. Ob daraus ein relevantes Risiko entsteht, hängt vom Kontext ab: Anwendungstyp, Authentisierungsmodell, Session-Handling, Reverse-Proxy-Verhalten, CDN, Browser-Kontext und Business-Logik. Deshalb gehört zu jedem passiven Finding eine manuelle Einordnung. Wer das ignoriert, produziert entweder Fehlalarme oder übersieht die eigentliche Tragweite.

Für einen stabilen Einstieg lohnt sich eine saubere Basis mit Scanner Anleitung und einer klaren Scanner Konfiguration. Ohne Scope, Filter und nachvollziehbaren Workflow wird aus passiver Analyse schnell ein unübersichtlicher Datenstrom, der zwar viele Meldungen erzeugt, aber wenig verwertbare Erkenntnis liefert.

Passives Scanning hängt vollständig von der Qualität des beobachteten Datenverkehrs ab. Wenn nur die Login-Seite besucht wurde, kann der Scanner auch nur diese Login-Seite bewerten. Wenn ein Testkonto nie in den Administrationsbereich gelangt, bleiben dortige Header, API-Antworten, Fehlerseiten und Session-Mechanismen unsichtbar. Die Aussagekraft des Scanners ist also direkt an die Abdeckung gekoppelt. Das klingt banal, ist aber einer der häufigsten Gründe für falsche Sicherheit.

Der erste technische Hebel ist der Scope. Ohne sauber definierten Scope landen schnell Third-Party-Domains, CDNs, Analytics-Endpunkte, Captcha-Dienste oder fremde APIs im Datenbestand. Das erzeugt Rauschen, verfälscht Prioritäten und kann im schlimmsten Fall zu Meldungen führen, die gar nicht zur eigentlichen Zielanwendung gehören. Ein professioneller Workflow trennt daher strikt zwischen In-Scope und Out-of-Scope, idealerweise bereits vor dem eigentlichen Browsing.

Ebenso entscheidend ist die Art, wie Traffic erzeugt wird. Wer nur manuell klickt, sieht oft nur Standardpfade. Wer dagegen Rollen wechselt, Fehler provoziert, Dateiuploads testet, API-Endpunkte anspricht, Session-Wechsel beobachtet und verschiedene Content-Typen abruft, liefert dem passiven Scanner deutlich mehr Material. Besonders bei Single-Page-Applications, GraphQL, REST-APIs und asynchronen Requests ist es wichtig, nicht nur die sichtbare Oberfläche zu betrachten. Viele interessante Antworten erscheinen nie direkt im Browserfenster, sondern nur als XHR-, Fetch- oder API-Traffic.

• Unterschiedliche Benutzerrollen erzeugen unterschiedliche Response-Strukturen und Header.
• Fehlerfälle liefern oft mehr sicherheitsrelevante Informationen als erfolgreiche Requests.
• Statische und dynamische Inhalte müssen getrennt betrachtet werden, weil Caching- und Header-Verhalten stark variieren kann.

Auch TLS, Zertifikatsinstallation und Proxy-Einbindung beeinflussen die Sichtbarkeit. Wenn HTTPS-Traffic nicht sauber abgefangen wird, fehlen genau die Antworten, die später bewertet werden sollen. In solchen Fällen lohnt sich ein Blick auf Zertifikat Installieren und Proxy Einrichten. Gerade mobile Browser, Electron-Apps oder lokal installierte Clients verhalten sich hier oft anders als ein Standardbrowser.

Ein weiterer Punkt ist die Session-Konsistenz. Wenn Requests wegen Timeouts, CSRF-Token-Wechseln oder Redirect-Schleifen fehlschlagen, sieht der Scanner nur unvollständige Antworten oder Login-Redirects. Das führt zu einer trügerischen Ruhe im Ergebnisfenster. Nicht weil die Anwendung sauber ist, sondern weil der relevante Traffic nie erfolgreich erfasst wurde.

Die meisten passiven Findings liegen nicht im Bereich spektakulärer Exploits, sondern in der Analyse von HTTP-Semantik. Genau dort passieren aber viele reale Sicherheitsfehler. Ein klassisches Beispiel sind fehlende oder schwache Security-Header. Wenn Content-Security-Policy, X-Frame-Options, X-Content-Type-Options oder Referrer-Policy fehlen oder widersprüchlich gesetzt sind, ist das nicht automatisch eine ausnutzbare Schwachstelle. Es ist jedoch ein belastbarer Hinweis auf fehlende Härtung und oft ein Indikator für weitere Defizite.

Cookies sind ein zweiter Kernbereich. Burp meldet etwa fehlende Secure-, HttpOnly- oder SameSite-Attribute. Die technische Bewertung muss dann tiefer gehen: Handelt es sich um Session-Cookies oder um unkritische Präferenzwerte? Wird die Anwendung ausschließlich über HTTPS betrieben? Gibt es Cross-Site-Navigationsflüsse, die SameSite=None erfordern? Werden mehrere Cookies mit ähnlichen Namen auf unterschiedlichen Pfaden gesetzt? Solche Details entscheiden darüber, ob ein Finding nur Hygiene betrifft oder eine echte Angriffsfläche darstellt.

Sehr häufig unterschätzt werden Cache-bezogene Hinweise. Antworten mit personenbezogenen Daten, Session-Informationen oder Account-Details dürfen nicht in gemeinsam genutzten Caches landen. Wenn Burp in sensitiven Antworten fehlende Cache-Control- oder Pragma-Direktiven erkennt, ist das ein ernstzunehmender Befund. Besonders kritisch wird es bei Reverse Proxies, CDN-Layern oder gemeinsam genutzten Browsern. Ein scheinbar kleiner Header-Fehler kann dann zur Offenlegung fremder Inhalte führen.

Informationslecks sind ein weiterer Bereich mit hoher Praxisrelevanz. Dazu gehören Server-Banner, Framework-Versionen, interne Hostnamen, Dateisystempfade, Stacktraces, Debug-IDs, Build-Informationen, API-Schemata oder versehentlich ausgelieferte Kommentare. Solche Details wirken isoliert oft harmlos. In Kombination mit bekannten CVEs, Standardpfaden, Default-Konfigurationen oder schwachen Admin-Oberflächen werden sie jedoch schnell operativ nutzbar.

Auch reflektierte Eingaben tauchen passiv auf. Wenn Parameterwerte in HTML, JSON, JavaScript oder Headern zurückgespiegelt werden, meldet Burp das häufig als Hinweis. Das ist noch kein Beweis für Xss, aber ein klarer Marker für manuelle Nachprüfung. Entscheidend ist der Kontext: HTML-Body, Attribut, Script-Block, JSON-String, URL, Header oder DOM-Sink. Erst diese Einordnung zeigt, ob aus einer Reflektion ein ausnutzbarer Vektor entstehen kann.

Wer Findings nur nach Schweregrad sortiert, verpasst oft die eigentliche Aussage. Ein „Low“ bei Cookie-Flags kann in einer hochsensiblen Anwendung relevanter sein als ein generischer „Medium“-Hinweis ohne Ausnutzbarkeit. Deshalb sollte jedes passive Ergebnis zusammen mit Asset-Typ, Authentisierung, Datenklassifikation und möglicher Angriffskette bewertet werden.

Passives Scanning produziert keine Wahrheit, sondern technische Beobachtungen. Ein häufiger Fehler besteht darin, jede Meldung als bestätigte Schwachstelle zu behandeln. Gerade bei Headern und Cookie-Attributen ist die Realität komplexer. Ein fehlendes Secure-Flag auf einem Cookie ist beispielsweise nur dann wirklich relevant, wenn das Cookie über unsichere Verbindungen übertragen werden kann oder Mischbetrieb existiert. In einer strikt HTTPS-erzwungenen Umgebung mit HSTS bleibt der Befund relevant, aber die praktische Ausnutzbarkeit kann deutlich geringer sein.

Ähnlich problematisch sind pauschale Bewertungen bei CORS, MIME-Typen oder Browser-Schutzmechanismen. Eine Meldung zu fehlendem X-Frame-Options ist nicht automatisch Clickjacking mit realem Impact. Eine reflektierte Eingabe ist nicht automatisch Script-Ausführung. Ein offengelegter Header ist nicht automatisch ein Einfallstor. Wer hier nicht sauber trennt, erzeugt Berichte voller theoretischer Risiken ohne operative Aussage.

Ein zweites Missverständnis betrifft die Quelle des Problems. Burp analysiert Antworten, aber nicht jede Auffälligkeit stammt aus der Zielanwendung selbst. Häufig kommen Header von Load Balancern, WAFs, CDNs, API-Gateways oder vorgeschalteten Webservern. Das ist für die Behebung wichtig. Wenn ein Security-Header an einer Stelle fehlt, kann die Ursache im Backend, im Reverse Proxy oder in einer Edge-Konfiguration liegen. Ohne diese Zuordnung wird remediation unnötig langsam.

Auch Content-Normalisierung führt oft zu Fehlinterpretationen. Manche Anwendungen setzen Header nur auf HTML-Seiten, nicht aber auf JSON-APIs oder Datei-Downloads. Andere überschreiben Header in Redirects, Fehlerseiten oder Legacy-Endpunkten. Ein einzelner Befund muss daher immer gegen mehrere Response-Typen geprüft werden. Genau dafür ist Repeater ideal: dieselbe Anfrage gezielt variieren, Redirects beobachten, Header vergleichen, Session-Zustände kontrollieren.

• Jede passive Meldung zuerst technisch verifizieren, bevor sie als Schwachstelle dokumentiert wird.
• Response-Kontext prüfen: Statuscode, Content-Type, Redirect-Kette, Authentisierungszustand, Cache-Verhalten.
• Infrastrukturanteile von Applikationslogik trennen, damit Ursache und Behebung korrekt zugeordnet werden.

Besonders wertvoll ist der Vergleich ähnlicher Antworten. Wenn ein Header nur auf 200-Responses vorhanden ist, aber auf 302-, 401- oder 500-Antworten fehlt, entsteht oft ein realer Sicherheitsunterschied. Solche Inkonsistenzen sind in großen Anwendungen häufig und werden durch rein oberflächliches Lesen der Findings leicht übersehen.

Für die eigentliche Einordnung lohnt sich außerdem ein Blick auf bekannte Kategorien aus Scanner Vulnerabilities. Nicht um Meldungen blind zu übernehmen, sondern um typische Muster, Voraussetzungen und Grenzen besser zu verstehen.

Ein guter Workflow mit passivem Scanning beginnt nicht im Scanner-Tab, sondern beim kontrollierten Erfassen des Traffics. Zuerst wird der Scope definiert, danach die Session vorbereitet, anschließend die Anwendung systematisch durchlaufen. Das Ziel ist nicht maximale Klickzahl, sondern maximale Abdeckung relevanter Zustände: anonym, authentisiert, privilegiert, fehlerhaft, abgelaufen, gesperrt, umgeleitet, API-basiert und dateibezogen.

In der Praxis hat sich eine Reihenfolge bewährt. Zuerst Basiserfassung über den Browser, dann gezielte Navigation durch Kernfunktionen, anschließend Prüfung von Sonderfällen. Parallel dazu wird die Dashboard-Sicht beobachtet, um neue Issues, Host-Aktivität und Scan-Hinweise früh zu erkennen. Danach folgt die manuelle Verifikation auffälliger Antworten in Repeater oder Comparer. Erst wenn ein Befund technisch verstanden ist, wird er priorisiert.

Ein professioneller Ablauf trennt außerdem Discovery von Bewertung. Während der Discovery-Phase wird möglichst viel relevanter Traffic erzeugt. In der Bewertungsphase werden Findings gruppiert: Header-Probleme, Cookie-Probleme, Informationslecks, Reflektionen, Caching, TLS-nahe Auffälligkeiten, API-Spezifika. Diese Gruppierung spart Zeit, weil ähnliche Ursachen oft an mehreren Endpunkten gleichzeitig auftreten.

Gerade bei großen Anwendungen ist es sinnvoll, Findings nicht endpointweise, sondern ursachenorientiert zu bearbeiten. Wenn zwanzig Antworten denselben fehlenden Header zeigen, ist das meist ein Konfigurationsproblem an zentraler Stelle. Wenn nur einzelne Legacy-Routen betroffen sind, liegt die Ursache eher in fragmentierter Applikationslogik. Diese Unterscheidung entscheidet darüber, ob eine Korrektur Minuten oder Wochen dauert.

Ein weiterer Bestandteil sauberer Workflows ist die Trennung zwischen passivem Hinweis und aktivem Folgecheck. Eine reflektierte Eingabe, ein verdächtiger CORS-Header oder ein ungewöhnlicher Redirect wird nicht sofort eskaliert, sondern zunächst reproduzierbar bestätigt. Danach kann gezielt mit Repeater Anleitung oder später mit aktiveren Methoden weitergearbeitet werden. So bleibt die Analyse nachvollziehbar und vermeidet unnötige Last auf dem Ziel.

Wer Burp nur als Sammelstelle für Meldungen nutzt, verschenkt Potenzial. Der eigentliche Wert entsteht aus der Verbindung von Traffic-Erfassung, Kontextanalyse, manueller Verifikation und sauberer Dokumentation. Genau dort trennt sich ein belastbarer Pentest von einem bloßen Tool-Export.

Ein typisches Beispiel ist eine Anwendung, die in mehreren Antworten interne Hostnamen und Versionsinformationen preisgibt. Passiv betrachtet ist das zunächst nur ein Informationsleck. In der Praxis kann daraus aber ein klarer Prüfpfad entstehen: Welche Komponenten sind betroffen? Gibt es bekannte Schwachstellen in der genannten Version? Existieren administrative Standardpfade? Werden interne APIs oder Debug-Endpunkte über dieselbe Infrastruktur bereitgestellt? Der passive Hinweis liefert also keine fertige Ausnutzung, aber eine belastbare Richtung.

Ein zweites Beispiel betrifft Cookies. Burp meldet ein Session-Cookie ohne SameSite. Allein daraus folgt noch kein Angriff. Wenn die Anwendung jedoch zustandsverändernde Aktionen per POST ohne zusätzliche Schutzmechanismen akzeptiert, entsteht ein konkreter Zusammenhang zu Csrf. Die passive Meldung ist dann der erste Marker, nicht der Endpunkt der Analyse. Entscheidend ist, ob Browser-Verhalten, Navigationsfluss und Serverlogik zusammen ein ausnutzbares Szenario ergeben.

Drittes Beispiel: Eine API liefert bei Fehlern vollständige Stacktraces mit Dateipfaden und Bibliotheksnamen. Das ist nicht nur unschön, sondern oft operativ verwertbar. Dateipfade verraten Deployment-Strukturen, Bibliotheken verraten Technologie-Stacks, Exception-Typen verraten Validierungslogik. Daraus lassen sich gezielte Folgeprüfungen ableiten, etwa auf unsichere Deserialisierung, schwache Upload-Validierung oder fehlerhafte Autorisierungspfade.

Auch Reflektionen sind ein klassischer Startpunkt. Wenn Burp einen Parameter in einer HTML-Antwort reflektiert sieht, wird der Kontext manuell geprüft. Erfolgt die Reflektion HTML-escaped? Liegt sie in einem Attribut? In einem Script-Block? In einem JSON-Blob, der clientseitig weiterverarbeitet wird? Erst diese Analyse zeigt, ob ein Pfad in Richtung Xss oder DOM-basierte Probleme existiert. Viele echte Funde beginnen genau mit so einem passiven Hinweis.

Ein weiteres realistisches Szenario ist inkonsistentes Caching. Eine Account-Seite setzt korrekte no-store-Header, ein PDF-Export mit denselben Daten jedoch nicht. Passiv fällt das durch unterschiedliche Response-Header auf. Daraus entsteht ein konkreter Prüfpfad: Browser-Cache, Proxy-Cache, Back-Button-Verhalten, gemeinsam genutzte Systeme, CDN-Regeln. Ohne passives Scanning würde diese Inkonsistenz oft unbemerkt bleiben, weil die Funktion fachlich korrekt arbeitet und nur auf HTTP-Ebene unsauber ist.

GET /account/export.pdf HTTP/1.1
Host: target.example
Cookie: session=abc123

HTTP/1.1 200 OK
Content-Type: application/pdf
Cache-Control: public, max-age=600
Set-Cookie: session=abc123; Path=/; HttpOnly

In diesem Beispiel ist nicht der PDF-Export selbst das Problem, sondern die Kombination aus sensitiven Inhalten und öffentlicher Cache-Freigabe. Solche Befunde wirken klein, sind aber in realen Umgebungen hochrelevant.

Passives Scanning ist stark, aber es hat klare Grenzen. Alles, was zusätzliche Interaktion, Zustandsänderung, Payload-Variation oder Timing-Analyse erfordert, bleibt weitgehend unsichtbar. Klassische Beispiele sind SQL Injection, Command Injection, SSRF, komplexe Access-Control-Fehler, Race Conditions, Business-Logic-Issues oder tiefe Authentisierungsprobleme. Ein passiver Hinweis kann auf solche Bereiche deuten, aber er bestätigt sie nicht.

Auch Autorisierungsfehler wie Idor lassen sich selten rein passiv erkennen. Der Scanner sieht zwar möglicherweise Objekt-IDs, Rollenhinweise oder verdächtige API-Strukturen, aber ohne gezielte Variation von Identifikatoren und Session-Kontext bleibt die eigentliche Schwachstelle verborgen. Dasselbe gilt für viele API-Probleme, bei denen erst der Vergleich zwischen Benutzerrollen oder Token-Typen die Lücke offenlegt.

Ein weiterer blinder Fleck sind clientseitige Logiken, die erst im Browser ausgeführt werden. Wenn Daten in JavaScript eingebettet sind, aber erst später in einen gefährlichen DOM-Sink fließen, reicht die reine Response-Analyse nicht aus. Hier muss der Datenfluss manuell nachvollzogen werden. Ebenso können WebSocket-Interaktionen, mobile App-Protokolle oder proprietäre Serialisierungsformate die passive Analyse einschränken.

Grenzen gibt es auch bei der Priorisierung. Burp kann technische Auffälligkeiten erkennen, aber nicht den geschäftlichen Impact. Ein fehlender Header auf einer Marketing-Seite ist anders zu bewerten als derselbe Fehler auf einem Banking-Portal. Ein Informationsleck in einer internen Admin-Antwort ist anders zu priorisieren als auf einer öffentlichen Fehlerseite. Diese Einordnung bleibt immer eine Aufgabe des Testers.

• Passive Ergebnisse zeigen Hinweise, keine vollständigen Angriffsnachweise.
• Business-Logik, Autorisierung und zustandsabhängige Fehler erfordern fast immer manuelle Folgeprüfungen.
• Die Relevanz eines Findings ergibt sich erst aus Technik, Kontext und möglichem Impact zusammen.

Deshalb sollte passives Scanning nie isoliert betrachtet werden. Es ist ein Frühwarnsystem, ein Korrelationstool und ein Qualitätsfilter für den weiteren Test. Wer diese Rolle versteht, nutzt es effizient. Wer erwartet, dass es den gesamten Web-Pentest ersetzt, wird zwangsläufig Lücken übersehen.

Auch passives Scanning kann unübersichtlich oder ineffizient werden, wenn die Umgebung schlecht konfiguriert ist. Ein typischer Fehler ist zu breiter Traffic-Einzug. Wenn Browser, Betriebssystem und Hintergrunddienste gleichzeitig über Burp laufen, füllt sich das Projekt mit irrelevanten Requests. Das erschwert nicht nur die Analyse, sondern belastet auch Speicher und Oberfläche. Saubere Filterung im Proxy und ein klarer Scope sind deshalb keine Komfortfunktion, sondern Grundvoraussetzung.

Ein zweiter Fehler ist die Vermischung mehrerer Testziele in einem Projekt. Dadurch werden Findings, Hosts, Sessions und Historien vermengt. Gerade bei ähnlichen Domains oder Staging-/Production-Kombinationen führt das schnell zu falschen Zuordnungen. Besser ist eine Trennung nach Ziel, Testphase oder Mandant. Wer regelmäßig mit mehreren Umgebungen arbeitet, sollte Projektoptionen und Benutzeroptionen bewusst einsetzen und nicht alles in einer einzigen Historie sammeln.

Performance-Probleme entstehen oft nicht durch den Scanner selbst, sondern durch große Projektdateien, umfangreiche Proxy-Historien, viele Mediendateien oder aggressive Browser-Nutzung. Wenn Burp träge wird, lohnt sich ein Blick auf Performance und auf die generelle Datenhygiene: irrelevante Hosts ausschließen, statische Assets filtern, alte Projekte archivieren, Browser-Tabs begrenzen, unnötige Extensions deaktivieren.

Fehlerquellen im Betrieb sind häufig banal: Zertifikat nicht korrekt installiert, Browser nutzt den Proxy nicht, mobile App pinnt Zertifikate, Session läuft ab, Login-Flow springt auf eine andere Domain, Requests werden durch WAF oder SSO umgeschrieben. In solchen Fällen scheint der passive Scanner „nichts zu finden“, obwohl in Wahrheit nur kein brauchbarer Traffic ankommt. Dann helfen strukturierte Checks über Debugging und bei Bedarf Seiten wie Scan Fehlgeschlagen.

Beobachtung:
- Proxy History zeigt fast nur 302 Redirects auf /login
- Scanner meldet kaum Findings
- Dashboard bleibt weitgehend leer

Wahrscheinliche Ursache:
- Session ist abgelaufen oder nie sauber aufgebaut
- Relevante Antworten werden nicht erreicht
- Passives Scanning analysiert nur Redirect-Ketten statt Zielinhalte

Ein weiterer Praxispunkt ist die Behandlung großer APIs. JSON-Antworten mit vielen Feldern, Tokens, IDs und Metadaten erzeugen zahlreiche Hinweise. Ohne Priorisierung verliert man schnell den Überblick. Hier hilft es, Findings nach Endpunkttyp, Sensitivität und Wiederholungsmuster zu gruppieren. Ein Header-Fehler auf hundert API-Routen ist meist ein Konfigurationsproblem, keine hundert Einzelprobleme.

Nicht jede passive Meldung gehört ungefiltert in einen Bericht. Berichtsfähig wird ein Hinweis erst dann, wenn technische Beobachtung, Relevanz und Reproduzierbarkeit sauber belegt sind. Dazu gehört mindestens: betroffener Endpunkt oder Muster, beobachtete Response, Sicherheitsauswirkung, Kontext der Anwendung und eine nachvollziehbare Empfehlung. Ohne diese Elemente bleibt ein Finding eine Rohnotiz.

Besonders wichtig ist die Trennung zwischen Einzelbefund und systemischem Problem. Wenn auf dutzenden Antworten derselbe Header fehlt, sollte das als zentrales Konfigurationsproblem dokumentiert werden, ergänzt um repräsentative Beispiele. Wenn nur einzelne Legacy-Endpunkte betroffen sind, ist eine präzisere Auflistung sinnvoll. Gute Dokumentation reduziert nicht nur Aufwand auf Verteidigerseite, sondern zeigt auch, ob das Problem architektonisch oder lokal begrenzt ist.

Bei passiven Findings sollte die Auswirkung realistisch formuliert werden. Ein fehlendes HttpOnly-Flag bedeutet nicht automatisch Session-Übernahme. Korrekt wäre: Das Cookie ist bei erfolgreicher clientseitiger Script-Ausführung potenziell lesbar, wodurch sich das Risiko einer Kompromittierung erhöht. Ebenso sollte ein Informationsleck nicht als „kritisch“ bezeichnet werden, wenn es lediglich generische Serverinformationen offenlegt. Präzision ist hier wichtiger als Dramatik.

Für belastbare Dokumentation lohnt sich die Kombination aus Original-Request, Original-Response und kurzer manueller Verifikation. Wenn ein Header auf mehreren Statuscodes inkonsistent ist, sollten diese Unterschiede explizit gezeigt werden. Wenn ein Cookie nur auf bestimmten Pfaden unsicher gesetzt wird, muss genau das dokumentiert werden. Burp liefert die Rohdaten, aber die Qualität des Befunds entsteht erst durch saubere Interpretation.

Ein gutes Muster für die Bewertung lautet: Was wurde beobachtet? Unter welchen Bedingungen? Warum ist das sicherheitsrelevant? Welche realistische Angriffsvoraussetzung besteht? Wie breit ist die Auswirkung? Wie lässt sich das Problem beheben? Diese Struktur verhindert, dass passive Hinweise entweder übertrieben oder bagatellisiert werden.

Wer den gesamten Ablauf professionalisieren will, sollte passives Scanning als festen Bestandteil eines größeren Workflow verstehen. Dort gehört es an den Anfang der technischen Bewertung, nicht an deren Ende. Es liefert die ersten belastbaren Signale, die später durch manuelle Analyse, Repeater-Tests und gegebenenfalls aktive Prüfungen verdichtet werden.