Target Site Map and Passive Scanning

What the Site Map Represents

The Burp site map is a hierarchical representation of the target application's structure. It shows you every URL Burp has seen — whether from proxy traffic, crawling, or manual entry — organized by host, path, and parameter. Think of it as the application's attack surface laid out visually.

How Burp Populates the Site Map

Burp builds the site map from two sources:

1. Proxy traffic — Every request that flows through Burp Proxy is automatically added to the site map. As you browse the application, the map grows in real time.

2. Crawling — Burp's crawler follows links discovered in responses, recursively discovering new paths and parameters. You start a crawl by right-clicking a host in the site map and selecting Crawl.

Site Map Structure

The site map is organized as a tree:

Target
├── https://target.example.com
│   ├── /
│   ├── /login
│   ├── /api
│   │   ├── /api/users
│   │   ├── /api/documents
│   │   └── /api/documents/{id}
│   └── /admin
│       └── /admin/dashboard

Each node shows the HTTP method, URL, and parameters. Clicking a node displays the full request and response in the bottom panel.

Configuring the Crawl

When you start a crawl, Burp presents options:

• Crawl strategy — "Deep" follows all links recursively; "Breadth-first" explores level by level
• Maximum crawl depth — Limits how many link hops the crawler follows (default is unlimited, but large apps may need limits)
• Number of threads — Controls crawl speed
• Scope — Only crawl URLs within the defined scope

For large applications, start with a focused crawl on a specific branch (e.g., /api) rather than the entire site. This keeps the crawl manageable and the results relevant.

Analyzing the Site Map

Once populated, the site map reveals:

• All discovered endpoints — Including ones not linked from the main navigation
• Parameter names — Every parameter Burp has observed, which you can fuzz in Intruder
• Content types — Which endpoints return HTML, JSON, XML, etc.
• Status codes — Which endpoints return 200, 302, 403, 500, etc.

Filter the site map by status code, MIME type, or annotation to focus on interesting areas. For example, filter for 403 responses to find endpoints that exist but require different authorization.

What Passive Scanning Does

Passive scanning analyzes requests and responses that already exist in Burp — it does not send any additional requests to the server. This makes it safe to run against production systems and invisible to intrusion detection systems.

What Passive Scanning Detects

Burp's passive scanner checks for:

• Missing security headers — No Content-Security-Policy, X-Frame-Options, Strict-Transport-Security, etc.
• Cookie issues — Session cookies without HttpOnly, Secure, or SameSite attributes
• Information disclosure — Error messages revealing stack traces, server versions, or internal paths
• Mixed content — HTTPS pages loading HTTP resources
• Email addresses — Exposed in page content
• Comments — HTML comments containing sensitive information

Running a Passive Scan

Passive scanning runs automatically on all proxied traffic. You do not need to start it. However, you can control what it checks:

1. Go to Scanner > Options (or Dashboard > Passive scan in newer versions)
2. Enable or disable specific check categories
3. Set the scan scope

To passive-scan a specific request or response, right-click it and select Do passive scan.

Reviewing Passive Scan Results

Passive scan findings appear in the Issues activity (Scanner tab) or as annotations in the site map. Each finding includes:

• Severity — High, Medium, Low, Information
• Confidence — Certain, Firm, Tentative
• Description — What was found and why it matters
• Remediation — How to fix the issue

Practical Example: Finding Missing Headers

You browse through the application with Burp proxying traffic. The passive scanner flags that no responses include X-Frame-Options or Content-Security-Policy. This means the application may be vulnerable to clickjacking. You verify by attempting to embed the site in an iframe — if it loads, clickjacking is confirmed.

Passive vs Active Scanning

Passive scanning is always your first pass. Active scanning comes later, against staging environments, when you are ready to probe for exploitable vulnerabilities.

Finding What Should Not Exist

The most valuable use of the site map is comparing what you discovered against what the application is supposed to do. This comparison exposes:

• Debug endpoints — /debug, /test, /dev, /console left accessible in production
• Administrative panels — /admin, /manage, /backend not linked from the main UI
• API versions — /api/v1, /api/v2, /api/internal with different behavior
• Backup files — /index.php.bak, /config.old, /database.sql
• Documentation — /swagger, /api-docs, /graphql with introspection enabled

Technique: Compare Against Declared Functionality

1. List declared features — From the application's marketing page, documentation, or user guide, list all known features and their expected URLs.
2. Export the site map — Right-click the site map > Save all items to a file.
3. Diff the lists — Any URL in the site map that is not in the declared feature list is a candidate for investigation.

Technique: Filter by Anomaly

Use the site map filter to find anomalies:

• Filter by 403/401 — Endpoints that exist but deny access; try different HTTP methods or authentication
• Filter by 500 — Endpoints that error; may reveal unhandled exceptions or debug information
• Filter by content type — JSON endpoints in an HTML application may be undocumented APIs
• Filter by parameter — Endpoints with debug, admin, test, or internal parameters

Practical Example: Discovering a Debug Endpoint

You are testing a web application. The site map shows a request to /api/debug/health that returns a 200 response with detailed system information (disk space, memory, database status). This endpoint is not linked from any page and was discovered by the crawler following a JavaScript file reference. The information disclosed helps you understand the server environment and plan further attacks.

Annotating the Site Map

As you analyze, annotate items in the site map:

• Right-click an item > Add annotation
• Note why the endpoint is interesting, what you tested, and what you found
• Annotations persist in the Burp project file and appear in reports

This creates a record of your analysis that you can reference later or share with team members.