Security Testing

Burp Suite Scanner Tutorial: Automated Vulnerability Detection

HelpMeTest

HelpMeTest

— 4 min read
Burp Suite Scanner Tutorial: Automated Vulnerability Detection

Burp Suite Professional's scanner automates the tedious parts of vulnerability discovery. Instead of manually testing every parameter for every vulnerability class, the scanner does systematic, repeatable coverage while you focus on manual testing of complex logic issues.

Prerequisite: Burp Suite Professional (scanner is not available in Community edition). This guide assumes authorized testing only.

How the Scanner Works

Burp's scanner is an active scanner — it sends crafted requests to the application and analyzes responses for vulnerability indicators. It doesn't just fingerprint; it actually tests inputs.

Phases:

  1. Audit — send payloads for each configured vulnerability class to every parameter in scope
  2. Analyze — compare responses against known patterns (SQL errors, reflected XSS, redirect headers)
  3. Report — log findings with severity, confidence, and evidence

The scanner is aware of context: it distinguishes between HTML contexts, JavaScript contexts, and JSON/XML contexts, choosing appropriate payloads for each.

Launching a Scan

Method 1: Scan from HTTP History

Best for targeted scanning of specific requests:

  1. In Proxy → HTTP History, find a request you want to scan
  2. Right-click → Scan
  3. A dialog opens with scan configuration options
  4. Configure scope and click OK

Method 2: Active Scan from Target

Scan the entire application in scope:

  1. Go to Target → Site Map
  2. Right-click your target → Actively scan this host
  3. Or right-click a specific folder → Actively scan this branch

Method 3: New Scan Wizard

From the Dashboard tab:

  1. Click New Scan
  2. Enter the URL(s) to scan
  3. Configure credentials, scope, and scan type
  4. Click OK

Scan Configuration

Crawl Settings

Configure how deeply Burp explores the application:

  • Crawl limit — maximum requests for crawling (higher = more coverage, slower)
  • Maximum link depth — how many levels of navigation to follow
  • Login credentials — add your test account so the crawler can reach authenticated content

Without credentials, the scanner only sees the unauthenticated surface.

Audit Settings

Choose which vulnerability classes to test:

High impact (always include):

  • SQL injection
  • OS command injection
  • Path traversal
  • XML/XXE injection
  • Server-side template injection

Common web vulnerabilities:

  • Cross-site scripting (reflected and stored)
  • HTTP header injection
  • Open redirect

Adjust based on your context:

  • Disable vulnerability classes that don't apply (e.g., XML injection if the app doesn't accept XML)
  • This reduces scan time and false positives

Speed and Noise

  • Normal speed — balanced, recommended for most testing
  • Minimize false positives — more conservative, fewer results, lower false positive rate
  • Minimize false negatives — aggressive, more findings but more false positives

For initial scans, start with normal speed.

Monitoring Active Scans

The Dashboard tab shows:

  • Active scan tasks and their progress
  • Issues discovered so far
  • Task log (requests sent, errors)

You can pause and resume scans. Large applications may take hours to scan fully.

Reviewing Scan Results

Go to Target → Issues (or the Dashboard → Issue activity panel):

Each issue includes:

  • Name — vulnerability type (e.g., "SQL injection")
  • Severity — High, Medium, Low, Information
  • Confidence — Certain, Firm, Tentative
  • URL and parameter — where the vulnerability was found
  • Evidence — the request/response that demonstrates the issue

Understanding Confidence Levels

  • Certain — Burp is confident this is a real vulnerability (e.g., database error message in response)
  • Firm — likely real, but worth manual verification
  • Tentative — possible, requires manual investigation to confirm

Focus on High severity + Certain confidence first. Don't report Tentative findings without manual verification.

Manually Verifying Findings

For each finding, verify manually:

  1. Click the issue to see the evidence
  2. Find the specific request in the evidence
  3. Send that request to Repeater
  4. Reproduce the finding manually
  5. Try variations to confirm it's exploitable (not a false positive)

False positives are common — a SQL error in a response doesn't always mean injection is possible; it might be a generic error message unrelated to your input.

Common Findings and What They Mean

SQL Injection (High/Certain): Burp found SQL syntax in the response triggered by its payload. Verify manually — can you extract data or authenticate as another user?

Reflected XSS (High/Certain): Your payload appeared in the response in an executable context. Verify the browser executes it, not just reflects it.

Path Traversal (High/Firm): A directory traversal sequence in a parameter returned file contents. Verify what files are accessible.

Stored XSS (High/Certain): A payload you submitted was stored and served back to other users. Critical — affects all users who visit the affected page.

Clickjacking (Low/Certain): The application can be embedded in an iframe on a malicious site. Check for X-Frame-Options or Content-Security-Policy headers.

Generating Reports

When scanning is complete:

  1. Go to Target → Issues or select issues in the Dashboard
  2. Right-click → Report selected issues
  3. Choose format: HTML or XML
  4. Configure report details (severity thresholds, include/exclude issue types)

The HTML report is suitable for sharing with stakeholders. The XML report is machine-readable for integration with issue trackers.

Scanning API Endpoints

For REST APIs:

  1. Import an API definition (OpenAPI/Swagger) via Target → Site Map → Import OpenAPI definition
  2. Burp generates requests for each endpoint
  3. Configure authentication headers
  4. Run the scanner against the imported endpoints

See Burp Suite for API testing for a detailed API scanning workflow.

Limitations

The scanner finds what it can test automatically. It won't catch:

  • Logic flaws — business logic vulnerabilities require understanding the application's intent
  • Access control issues — testing whether User A can access User B's data requires two authenticated sessions
  • Race conditions — concurrent request vulnerabilities need specialized testing
  • Second-order injection — payloads stored and executed later in different contexts

Manual testing is still necessary alongside automated scanning. The scanner handles systematic coverage; you handle the subtle issues.

Related:

Read more

Start now free