Target Tab: Anwendung, typische Fehler, Praxiswissen und saubere Workflows

Der Target Tab ist in Burp Suite kein dekorativer Navigationspunkt, sondern die zentrale Sicht auf die Angriffsoberfläche einer Webanwendung. Wer nur mit Proxy History arbeitet, sieht einzelne Requests. Wer den Target Tab sauber nutzt, erkennt Struktur, Beziehungen, wiederkehrende Parameter, API-Pfade, Hostnamen, Session-abhängige Bereiche und tote Endpunkte. Genau dieser Unterschied trennt hektisches Klicken von systematischer Analyse.

Im praktischen Einsatz erfüllt der Target Tab drei Kernaufgaben: Erstens bildet er die beobachtete Anwendung in einer Site Map ab. Zweitens begrenzt er mit Scope-Regeln, was relevant ist und was nicht. Drittens dient er als Ausgangspunkt für Folgeaktionen in Repeater, Intruder oder Scanner. Ohne diese Ordnung entstehen schnell typische Fehler: Requests an fremde Hosts landen im Test, Logout-Links werden versehentlich ausgelöst, statische Assets überfluten die Ansicht und kritische Endpunkte gehen im Rauschen unter.

Besonders in größeren Anwendungen mit mehreren Subdomains, CDN-Ressourcen, API-Gateways und externen Authentifizierungsdiensten ist der Target Tab unverzichtbar. Eine Login-Seite auf app.example.tld kann Requests an auth.example.tld, api.example.tld, cdn.example.net und analytics-Dienste erzeugen. Ohne Scope und saubere Host-Bewertung wird die Site Map unbrauchbar. Mit sauberer Konfiguration wird sie dagegen zu einer belastbaren Inventarliste der tatsächlich erreichten Oberfläche.

Der Target Tab ist eng mit Scope, Proxy History und Workflow verknüpft. Die Proxy-Komponente liefert Rohdaten, der Target Tab verdichtet sie zu Struktur. Genau deshalb beginnt ein sauberer Test nicht mit Payloads, sondern mit Sichtbarkeit: Welche Hosts existieren, welche Pfade sind erreichbar, welche Parameter tauchen wiederholt auf, welche Antworten unterscheiden sich nach Rolle, Session oder HTTP-Methode?

Ein häufiger Anfängerfehler besteht darin, den Target Tab als passives Archiv zu betrachten. In der Praxis ist er ein aktives Arbeitsinstrument. Von dort aus werden Requests an Repeater gesendet, Scanner-Ziele ausgewählt, Kontextmenüs für Inhaltsentdeckung genutzt und Scope-Regeln nachgeschärft. Wer den Target Tab ignoriert, testet oft nur das, was zufällig im Browser geöffnet wurde. Wer ihn beherrscht, testet die Anwendung als System.

Die Site Map im Target Tab zeigt nicht einfach nur URLs. Sie zeigt beobachtete Ressourcen in einer hierarchischen Struktur, gruppiert nach Protokoll, Host, Port und Pfad. Diese Darstellung ist wertvoll, weil sie technische Muster sichtbar macht, die in einer linearen Request-Liste kaum auffallen. Dazu gehören etwa parallele API-Versionen wie /api/v1 und /api/v2, Admin-Bereiche, Upload-Verzeichnisse, Export-Funktionen, Debug-Endpunkte oder Parameterfamilien mit ähnlicher Semantik.

Ein erfahrener Blick auf die Site Map bewertet nicht nur, was vorhanden ist, sondern auch, was ungewöhnlich wirkt. Ein Pfad wie /internal/report/export kann harmlos sein, aber in Kombination mit Parametern wie format, userId oder template wird daraus schnell ein Kandidat für IDOR, Dateizugriff oder serverseitige Template-Probleme. Ein Endpunkt /api/users/123/profile ist nicht nur ein API-Pfad, sondern ein Hinweis auf Objektzugriffsmuster. Genau an solchen Stellen beginnt echte Analyse.

Wichtig ist außerdem die Trennung zwischen navigationsgetriebenen und datengetriebenen Requests. Ein Browser erzeugt beim Laden einer Seite HTML, JavaScript, CSS, Bilder, Fonts und API-Aufrufe. In der Site Map sollten diese Elemente nicht gleich behandelt werden. JavaScript-Dateien können versteckte Endpunkte verraten, statische Bilder sind meist irrelevant, API-Calls enthalten dagegen oft die eigentliche Geschäftslogik. Wer die Site Map nur nach sichtbaren Seiten bewertet, übersieht oft die interessanteren JSON-Endpunkte im Hintergrund.

Die Parameteranalyse beginnt ebenfalls im Target Tab. Wiederkehrende Namen wie id, user, account, file, redirect, returnUrl, next, token oder role sind keine Schwachstellen, aber starke Indikatoren für Testpfade. Ein Parameter namens id in zehn verschiedenen Endpunkten deutet auf ein Objektmodell hin. Ein redirect-Parameter in Login- oder Logout-Flows deutet auf Open-Redirect-Potenzial hin. Ein file-Parameter in Download-Funktionen kann auf Pfadmanipulation oder unsichere Dateireferenzen hindeuten.

Hilfreich ist eine mentale Einteilung der Site Map in Funktionszonen:

• Authentifizierung und Session: Login, Logout, Passwort-Reset, MFA, Token-Refresh, Profilwechsel
• Geschäftslogik und Datenzugriff: API-Endpunkte, Suchfunktionen, Exporte, Uploads, Objektansichten, Rollenwechsel
• Infrastruktur und Hilfsfunktionen: Health-Checks, Debug-Pfade, statische Assets, Third-Party-Integrationen, Dokumentation

Diese Einteilung verhindert, dass die Analyse an der Oberfläche hängen bleibt. Ein sauberer Pentest betrachtet nicht nur Seiten, sondern Datenflüsse. Genau dafür ist die Site Map im Target Tab gemacht.

Der Scope entscheidet darüber, ob Burp Suite ein präzises Prüfwerkzeug oder ein Sammelbehälter für irrelevanten Traffic ist. In realen Anwendungen werden oft Dutzende Hosts kontaktiert: Hauptanwendung, API, Auth-Provider, CDN, Telemetrie, Chat-Widgets, Zahlungsdienste, Kartenanbieter und Werbeplattformen. Ohne Scope landet alles in derselben Arbeitsoberfläche. Das kostet Zeit, erhöht Fehlerrisiken und kann im schlimmsten Fall zu Tests auf nicht freigegebenen Systemen führen.

Ein sauberer Scope wird nicht erst nachträglich gesetzt, sondern vor der eigentlichen Erkundung. Dazu gehören Hostnamen, Protokolle, Ports und bei Bedarf Pfadgrenzen. Wenn nur /app und /api im Prüfauftrag enthalten sind, gehört /support oder eine externe SSO-Domain nicht automatisch dazu. Gerade bei Bug-Bounty- oder Kundenprojekten ist diese Trennung nicht optional, sondern Teil professioneller Arbeitsweise. Ergänzend lohnt sich ein Blick auf Burp Suite Legalität und Ethisches Hacking, weil Scope-Fehler schnell rechtliche und vertragliche Folgen haben können.

Technisch betrachtet wirkt Scope an mehreren Stellen. Er filtert Ansichten, begrenzt Folgeaktionen und reduziert versehentliche Interaktionen mit Fremdsystemen. Besonders nützlich ist die Option, nur In-Scope-Elemente anzuzeigen. Dadurch wird die Site Map deutlich lesbarer. Gleichzeitig darf Scope nicht zu eng gesetzt werden. Wenn auth.example.tld für den Login zwingend benötigt wird, aber nicht im Scope liegt, fehlen wichtige Requests in der Analyse. Scope muss also präzise, aber funktionsorientiert definiert werden.

Ein häufiger Fehler ist die Verwechslung von Sichtbarkeit und Freigabe. Nur weil ein Browser einen Host kontaktiert, ist dieser nicht automatisch testbar. Umgekehrt kann ein Host testrelevant sein, obwohl er im normalen Klickpfad zunächst nicht sichtbar ist, etwa eine API-Subdomain, die erst nach JavaScript-Analyse auffällt. Deshalb sollte Scope immer mit dem tatsächlichen Anwendungsdesign abgeglichen werden, nicht nur mit dem ersten Seitenaufruf.

In der Praxis bewährt sich folgender Ansatz: Zuerst Kernhosts identifizieren, dann Scope setzen, danach gezielt browsen und die Site Map kontrollieren. Wenn neue Hostnamen auftauchen, werden sie bewertet statt reflexartig übernommen. Diese Disziplin spart später massiv Zeit, vor allem wenn Scanner, Intruder oder manuelle Tests auf Basis der Site Map gestartet werden.

Der eigentliche Wert des Target Tabs zeigt sich, wenn aus Struktur konkrete Testarbeit wird. Aus der Site Map lassen sich verdächtige Requests direkt an andere Burp-Komponenten übergeben. Das ist mehr als Komfort. Es sorgt dafür, dass Tests aus einem nachvollziehbaren Kontext heraus erfolgen: Der Request stammt aus einer realen Anwendungssituation, mit echten Headern, Cookies, Parametern und oft auch korrekter Reihenfolge im Workflow.

Für manuelle Verifikation ist der Übergang zu Repeater besonders wichtig. Ein Endpunkt aus der Site Map kann dort isoliert untersucht werden: Parameter ändern, Methoden wechseln, Header entfernen, Rollen simulieren, IDs austauschen, Content-Type variieren oder Grenzwerte testen. Der Target Tab liefert also nicht nur eine Liste von URLs, sondern die Startpunkte für reproduzierbare Einzeltests.

Für systematische Variationen ist die Übergabe an Intruder sinnvoll. Das gilt etwa bei numerischen IDs, Rollenparametern, Dateinamen, Redirect-Zielen oder API-Feldern, die auf Enumerations- oder Autorisierungsprobleme hindeuten. Entscheidend ist dabei die Vorarbeit im Target Tab: Nur wenn klar ist, welche Endpunkte wirklich geschäftsrelevant sind, lohnt sich eine Intruder-Kampagne. Sonst werden Ressourcen auf irrelevante Assets oder rein dekorative Requests verschwendet.

Auch der Scanner profitiert von einer sauberen Zielauswahl. Wer wahllos ganze Hosts scannt, produziert oft Lärm, Last und Fehlalarme. Wer aus der Site Map gezielt Login-nahe Funktionen, Uploads, Suchfelder, JSON-APIs oder administrative Pfade auswählt, erhält deutlich bessere Ergebnisse. Gerade in komplexen Anwendungen ist die Qualität der Zielauswahl oft wichtiger als die reine Menge der gescannten Requests.

Ein praxistauglicher Ablauf sieht so aus:

• Im Target Tab auffällige Hosts, Pfade und Parameter identifizieren
• Relevante Requests an Repeater senden und Verhalten manuell verifizieren
• Wiederholbare oder parametergetriebene Muster an Intruder oder Scanner übergeben

Dieser Ablauf verhindert blinden Aktionismus. Erst Sichtbarkeit, dann Hypothese, dann Verifikation. Genau so wird aus dem Target Tab ein operatives Zentrum statt einer bloßen Übersicht.

Viele Probleme im späteren Testverlauf entstehen nicht in Repeater oder Intruder, sondern viel früher im Target Tab. Der häufigste Fehler ist ein unsauberer Start. Wenn Burp ohne klare Projekttrennung, ohne Scope und ohne Browser-Hygiene verwendet wird, landet alter Traffic aus anderen Sessions neben aktuellem Testmaterial. Das verfälscht die Sicht auf die Anwendung. Ein Endpunkt wirkt dann erreichbar, obwohl er aus einem früheren Login stammt oder zu einem anderen Projekt gehört.

Ein weiterer Klassiker ist die Vermischung von Benutzerrollen. Wird zuerst als normaler Benutzer und später als Administrator getestet, ohne die Requests sauber zu trennen, verliert die Site Map ihren Aussagewert. Dann ist nicht mehr erkennbar, welche Ressourcen wirklich welcher Rolle zugänglich sind. Gerade bei Autorisierungstests ist das fatal. Der Target Tab sollte deshalb immer im Kontext der aktiven Session gelesen werden. Unterschiedliche Rollen gehören in getrennte Projekte oder mindestens in klar getrennte Testphasen.

Ebenso problematisch ist das Ignorieren von Methoden und Antwortmustern. Ein Pfad, der per GET sichtbar ist, kann per POST ganz andere Funktionen auslösen. Ein API-Endpunkt mit 200 OK ist nicht automatisch erfolgreich; oft liefert erst der Response-Body die eigentliche Aussage. Wer im Target Tab nur auf Pfadnamen schaut, übersieht semantische Unterschiede zwischen Lesen, Erstellen, Aktualisieren und Löschen.

Auch Third-Party-Traffic wird oft falsch bewertet. Externe Skripte, Telemetrie oder Zahlungsanbieter tauchen in der Site Map auf und sehen technisch interessant aus. Ohne Prüfauftrag und Kontext sind sie aber nicht automatisch Teil des Tests. Hier hilft eine strikte Scope-Disziplin. Wenn Burp unerwartet unübersichtlich wird, lohnt sich meist zuerst ein Blick auf Proxy Filter und Einstellungen, bevor an der Anwendung selbst nach Fehlern gesucht wird.

Ein besonders teurer Fehler ist das Übersehen von API-Endpunkten, weil nur die sichtbare Weboberfläche betrachtet wird. Moderne Anwendungen verlagern Geschäftslogik in XHR- oder Fetch-Requests. In der Site Map erscheinen diese oft unter /api, /graphql, /rest oder ähnlichen Pfaden. Wer sich nur an HTML-Seiten orientiert, testet die Fassade und verpasst die eigentlichen Angriffsflächen.

Schließlich führt auch fehlende Bereinigung zu Problemen. Eine überladene Site Map mit Tausenden irrelevanten Requests erschwert jede Priorisierung. Dann werden wichtige Endpunkte nicht mehr gesehen, weil sie zwischen Fonts, Tracking-Calls und statischen Assets verschwinden. Gute Arbeit im Target Tab bedeutet deshalb auch, irrelevante Daten konsequent auszublenden oder gar nicht erst zu sammeln.

Ein realistisches Beispiel zeigt, wie der Target Tab in der Praxis genutzt wird. Angenommen, eine Anwendung besitzt die Hosts app.example.tld und api.example.tld. Nach dem Login erscheinen in der Site Map unter api.example.tld mehrere Pfade: /api/profile, /api/orders, /api/orders/4812, /api/orders/4812/invoice und /api/users/4812/preferences. Schon diese Struktur liefert mehrere Hypothesen. Die wiederkehrende numerische ID 4812 kann eine Benutzer- oder Objekt-ID sein. Die Trennung zwischen orders und users deutet auf unterschiedliche Objektklassen hin. Der Pfad invoice legt Dateiausgabe oder Dokumentenzugriff nahe.

Der erste Schritt ist nicht sofortiges Fuzzing, sondern Kontextprüfung. Gehört 4812 zur eigenen Session? Ändert sich die ID bei einem zweiten Benutzer? Sind die IDs fortlaufend? Wird im Frontend nur die eigene Bestellung angezeigt, obwohl die API eine direkte Objektadresse verwendet? Genau hier zeigt der Target Tab seinen Wert: Er offenbart das Objektmodell, bevor einzelne Requests manipuliert werden.

Ein möglicher Folgeablauf wäre: Request /api/orders/4812 an Repeater senden, ID auf 4811 oder 4813 ändern, Antwortcodes und Inhalte vergleichen. Wenn die Antwort weiterhin Daten liefert, liegt ein starker Hinweis auf Idor vor. Falls stattdessen ein Invoice-Endpunkt PDF-Dateien anhand einer numerischen Referenz ausliefert, kann zusätzlich geprüft werden, ob Dokumente anderer Benutzer abrufbar sind. Der Target Tab hat in diesem Szenario nicht die Schwachstelle gefunden, aber die Struktur geliefert, aus der eine belastbare Testhypothese entsteht.

Ein zweites Beispiel betrifft Redirect-Parameter. In der Site Map tauchen /login, /logout und /auth/callback mit Parametern wie returnUrl oder next auf. Diese Muster sind klassische Kandidaten für Open Redirect oder Authentifizierungsfehler. Der Target Tab macht sichtbar, an welchen Stellen Navigationslogik zentralisiert ist. Erst danach folgt die manuelle Prüfung im Repeater.

Ein drittes Beispiel betrifft Upload-Funktionen. In der Site Map erscheinen /profile/upload, /documents/upload und /api/files/process. Schon diese Kombination zeigt, dass Upload und serverseitige Verarbeitung getrennt sein können. Das ist relevant für File Upload-Tests, weil Validierung, Speicherung und Verarbeitung oft in unterschiedlichen Endpunkten stattfinden. Ohne die Gesamtansicht im Target Tab würde leicht nur der erste Schritt getestet.

GET /api/orders/4812 HTTP/1.1
Host: api.example.tld
Cookie: session=abc123
Accept: application/json

HTTP/1.1 200 OK
Content-Type: application/json

{"orderId":4812,"userId":4812,"total":199.00,"status":"paid"}

Wenn bei Änderung auf /api/orders/4813 weiterhin ein valider Datensatz erscheint, ist das kein Zufallsfund, sondern das Ergebnis sauberer Vorarbeit im Target Tab. Genau so entsteht belastbare Testtiefe.

Je größer die Anwendung, desto wichtiger wird ein disziplinierter Workflow im Target Tab. Bei Single-Page-Applications, mobilen APIs, GraphQL-Endpunkten oder SSO-gestützten Logins reicht es nicht, ein paar Seiten anzuklicken. Die Site Map muss aktiv aufgebaut werden. Dazu gehört, typische Benutzerpfade vollständig zu durchlaufen: Registrierung, Login, Passwortwechsel, Profilbearbeitung, Suche, Objektansicht, Export, Upload, Rollenwechsel, Logout. Nur so entsteht ein repräsentatives Bild der Anwendung.

Bei APIs ist der Target Tab besonders wertvoll, weil viele Endpunkte nie direkt im Browser sichtbar werden. Ein Frontend kann mit wenigen Klicks Dutzende Hintergrundaufrufe erzeugen. Diese Calls zeigen oft Parameter, Header, Tokens, Versionspfade und Fehlerbehandlungen, die in der Oberfläche verborgen bleiben. Für API-nahe Prüfungen lohnt sich ergänzend ein Blick auf API Testing und Session Management, weil viele Probleme erst im Zusammenspiel von Authentifizierung, Rollen und Objektzugriff sichtbar werden.

Mehrstufige Logins mit SSO, OAuth oder MFA erfordern zusätzliche Sorgfalt. Hier entstehen oft mehrere Hosts und Redirect-Ketten, die in der Site Map zunächst chaotisch wirken. Wichtig ist, die Authentifizierungsstrecke von der eigentlichen Anwendungslogik zu trennen. Nicht jeder SSO-Request ist testrelevant, aber die Übergänge zwischen Identitätsprovider und Zielanwendung sind oft sicherheitskritisch. Token-Übergaben, Callback-Parameter, State-Werte und Session-Bindung sollten deshalb bewusst beobachtet werden.

Für große Anwendungen hat sich folgende Arbeitsweise bewährt:

• Pro Rolle und Testziel getrennte Sessions oder Projekte verwenden
• Scope früh setzen und bei neuen Hosts bewusst nachschärfen
• Site Map regelmäßig auf interessante Pfade, APIs und wiederkehrende Parameter prüfen
• Verdächtige Requests sofort markieren oder in Repeater überführen, statt sie später suchen zu müssen
• Statische Assets, Telemetrie und irrelevante Drittanbieter konsequent aus der Analyse herausfiltern

Dieser Workflow reduziert nicht nur Unordnung, sondern verbessert auch die Qualität der Befunde. Schwachstellen entstehen selten isoliert. Sie zeigen sich in Abläufen, Zustandswechseln und Objektbeziehungen. Der Target Tab ist die Stelle, an der diese Zusammenhänge zuerst sichtbar werden.

Wenn der Target Tab leer bleibt oder unvollständig wirkt, liegt das Problem meist nicht am Tab selbst, sondern an der Erfassungskette. Zuerst muss geprüft werden, ob der Browser tatsächlich über Burp läuft. Fehlt die Proxy-Konfiguration oder ist das Zertifikat nicht sauber eingebunden, erscheinen HTTPS-Ziele unvollständig oder gar nicht. In solchen Fällen helfen meist die Themen Proxy Einrichten, Zertifikat Installieren und Proxy Verbindungsfehler.

Ein weiteres Problem ist Browser-Caching. Wenn Seiten aus dem Cache geladen werden, sieht Burp weniger Requests als tatsächlich für die Anwendung relevant wären. Das führt zu lückenhaften Site Maps. Gerade bei JavaScript-lastigen Anwendungen kann das bedeuten, dass zentrale API-Calls fehlen. Deshalb sollte für ernsthafte Tests mit einem sauberen Browserprofil oder einem eingebetteten Browser gearbeitet werden, der kontrolliert über Burp läuft.

Auch Scope-Filter können Verwirrung stiften. Wenn nur In-Scope-Elemente angezeigt werden, aber der relevante Host nicht im Scope liegt, wirkt die Site Map leer. Das ist kein Erfassungsfehler, sondern ein Konfigurationsproblem. Umgekehrt kann ein zu weiter Scope die Ansicht so stark aufblasen, dass relevante Ziele untergehen. Gute Fehleranalyse beginnt deshalb immer mit der Frage: Fehlen Daten wirklich, oder werden sie nur ausgeblendet?

Bei modernen Frontends kommt hinzu, dass manche Inhalte über WebSockets, Hintergrund-Requests oder dynamische JavaScript-Logik geladen werden. Wenn nur klassische Seitenaufrufe betrachtet werden, bleibt die Site Map unvollständig. In solchen Fällen muss die Anwendung aktiv benutzt werden, statt nur Startseiten zu laden. Formulare absenden, Filter ändern, Suchfunktionen nutzen, Tabs wechseln, Exporte auslösen und Fehlerfälle provozieren. Erst dann zeigt der Target Tab die tatsächliche Oberfläche.

Wenn Burp insgesamt instabil wirkt oder Requests nicht konsistent auftauchen, lohnt sich ergänzend ein Blick auf Debugging, Fehler und Funktioniert Nicht. In der Praxis sind es oft kleine Konfigurationsfehler, die später als vermeintliche Anwendungsprobleme fehlinterpretiert werden.

Der größte Mehrwert des Target Tabs liegt nicht in der bloßen Sichtbarkeit, sondern in der Priorisierung. Eine gute Site Map beantwortet die Frage, wo Testzeit den höchsten Ertrag bringt. Nicht jeder Endpunkt ist gleich interessant. Priorität haben Funktionen mit direktem Datenzugriff, Zustandsänderungen, Rollenbezug, Dateiverarbeitung, Weiterleitungen, serverseitiger Verarbeitung und komplexer Eingabelogik.

Ein erfahrener Pentester liest die Site Map deshalb wie ein Modell der Geschäftslogik. Endpunkte wie /admin/users, /api/export, /billing/invoice, /documents/download, /profile/avatar, /auth/callback oder /search?q= sind nicht nur technische Ziele, sondern Hinweise auf typische Fehlerklassen. Export- und Download-Funktionen sprechen für Autorisierungs- und Dateizugriffstests. Such- und Filterfunktionen sind Kandidaten für Injection- oder Logikfehler. Callback- und Redirect-Pfade sind relevant für Authentifizierungs- und Navigationsprobleme.

Wichtig ist dabei die Kombination aus Struktur und Verhalten. Ein Pfad allein ist nur ein Hinweis. Erst wenn Response-Größe, Statuscodes, Redirects, Fehlermeldungen, Objekt-IDs und Session-Abhängigkeiten mitbetrachtet werden, entsteht eine belastbare Priorität. Der Target Tab liefert die Struktur, die Detailprüfung erfolgt anschließend in Repeater, Intruder oder Scanner. Wer diese Reihenfolge einhält, arbeitet deutlich effizienter als mit rein zufälligem Request-Picking.

Ein gutes Beispiel ist die Unterscheidung zwischen horizontaler und vertikaler Autorisierung. Wenn die Site Map zeigt, dass normale Benutzer und Administratoren ähnliche Pfade mit unterschiedlichen Präfixen nutzen, etwa /user/orders und /admin/orders, entsteht sofort eine Testidee: Lassen sich Admin-Funktionen mit Benutzer-Session aufrufen? Wenn dagegen dieselben Pfade mit unterschiedlichen Objekt-IDs auftauchen, ist eher horizontale Autorisierung relevant. Diese Art von Ableitung ist nur möglich, wenn die Site Map bewusst gelesen wird.

Auch Performance und Testökonomie spielen eine Rolle. Wer den Target Tab sauber nutzt, vermeidet unnötige Last auf irrelevanten Endpunkten und konzentriert sich auf die Teile der Anwendung, die echte Aussagekraft haben. Das verbessert nicht nur die Qualität der Ergebnisse, sondern reduziert auch Seiteneffekte im Testbetrieb. Gerade in produktionsnahen Umgebungen ist das ein wesentlicher Teil professioneller Arbeitsweise.

Am Ende steht ein einfaches Prinzip: Der Target Tab ist die Landkarte. Ohne Landkarte wird getestet, was zufällig sichtbar ist. Mit Landkarte wird getestet, was wahrscheinlich verwundbar, geschäftskritisch oder logisch angreifbar ist. Genau das macht den Unterschied zwischen Werkzeugbedienung und methodischem Web-Pentest.