Burp Suite Testing V2

Burp Suite Web Application Testing

Overview

Use this skill for authorized web application security testing with Burp Suite when the task requires a controlled workflow across proxying, request inspection, replay, authenticated testing, targeted scanning, and manual verification.

This skill is for operators who need to produce defensible testing results rather than just “run Burp.” It emphasizes:

• strict in-scope-only handling
• safe scan configuration
• authenticated and session-aware testing
• HTTP/API workflow coverage
• reproducible evidence and findings notes

AUTHORIZED USE ONLY: Perform testing only with explicit permission and documented scope. Do not use this skill for opportunistic, production-hostile, or out-of-scope activity.

When to Use

Use this skill when all of the following are true:

• the user is performing an authorized web security assessment
• traffic needs to be observed, modified, replayed, or compared
• manual validation is required after automated discovery
• session handling, login state, cookies, tokens, or API requests matter
• the operator must preserve a clear audit trail of what was tested and why

Do not use this skill when:

• authorization is missing or ambiguous
• the target scope is unknown, disputed, or still changing
• the task is limited to static code review with no live HTTP behavior
• testing would require aggressive actions that the owner has not approved
• the environment cannot tolerate proxying, scanning, or replay traffic

Inputs

Prepare these inputs before starting:

• written authorization or ticket reference
• target list: hosts, ports, paths, APIs, environments
• excluded targets or prohibited test classes
• Burp edition and available capabilities in the operator environment
• browser trust/proxy setup status
• test account details or approved authentication method
• API auth material if applicable: bearer token, cookie, API key, client cert
• rate-limit or maintenance-window constraints

Outputs

Produce outputs that another reviewer can verify:

• scoped testing notes with time, target, and operator identity
• saved Burp project or equivalent request history
• issue list with evidence, reproduction steps, and severity rationale
• manual validation notes tied to request/response pairs
• clear record of skipped tests, blocked areas, and safety constraints

Workflow

1. Confirm authorization and freeze scope

   • Record the approval source and exact target boundaries.
   • Add only in-scope hosts, protocols, and URLs to Burp target scope.
   • Define exclusions before proxying or scanning.
   • If scope is unclear, stop and resolve it before sending traffic.

2. Prepare the Burp test environment

   • Configure the Burp proxy and browser trust settings.
   • Use Burp's browser or a dedicated testing browser profile.
   • Disable unrelated tabs, extensions, and background apps that may leak traffic into scope.
   • Verify that only intended traffic is passing through Burp.

3. Establish a clean baseline session

   • Browse the application normally first.
   • Capture login flow, session cookies, CSRF tokens, redirects, and API preflight behavior.
   • For authenticated assessments, verify that requests remain associated with the intended test account.
   • Note any MFA, token rotation, idle timeout, or device-binding behavior.

4. Map the application and isolate interesting traffic

   • Identify high-value requests: authentication, authorization, state change, search, file upload, admin actions, and API mutation endpoints.
   • Send representative requests to Repeater for controlled replay.
   • Group endpoints by function so testing stays organized.
   • For APIs, note content type, auth method, versioning, and expected error shape.

5. Perform targeted manual manipulation

   • Modify one variable at a time in Repeater.
   • Compare baseline vs modified responses for status code, body, timing, and side effects.
   • Test parameter trust boundaries, server-side validation, method handling, and access control.
   • For JSON or API traffic, keep payload structure valid while changing only the security-relevant field.
   • For HTTP/2 or modern browser-driven features, confirm Burp is observing the actual protocol path used by the app.

6. Run narrowly configured automated checks

   • Scan only in-scope, relevant items.
   • Choose a scan configuration appropriate to the environment’s safety limits.
   • Prefer targeted scans after mapping and authentication validation rather than broad early scans.
   • Watch for logout, rate-limit, lockout, or unstable-session signals during the run.
   • If the app uses recorded login/session handling, verify that Burp is maintaining the intended authenticated state.

7. Validate, document, and close out

   • Confirm suspected findings manually before reporting them as real issues.
   • Map findings to OWASP WSTG-style categories where useful.
   • Save the exact request/response evidence needed for reproduction.
   • Record negative results where they materially reduce uncertainty.
   • Remove proxy settings and securely handle captured credentials or tokens after the assessment.

Examples

Example 1: Authorization check in a JSON API

Captured request

PATCH /api/v1/users/245/role HTTP/2
Host: app.example.test
Authorization: Bearer eyJhbGciOi...
Content-Type: application/json

{"role":"viewer"}

Manual test in Repeater

Change only the object identifier while keeping the same user session:

PATCH /api/v1/users/246/role HTTP/2
Host: app.example.test
Authorization: Bearer eyJhbGciOi...
Content-Type: application/json

{"role":"admin"}

Expected secure behavior

HTTP/2 403 Forbidden
Content-Type: application/json

{"error":"insufficient_permissions"}

Concerning behavior

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

{"id":246,"role":"admin","updated":true}

Interpretation: this suggests broken object-level or function-level authorization and requires manual confirmation of side effects.

Example 2: Session handling problem during scanning

Symptoms during scan

• scanner results suddenly shift from authenticated pages to login pages
• many findings become duplicates against /login
• responses change from 200 application pages to 302 redirects or 401/403

Expected operator action

• pause or narrow the scan
• re-validate the authenticated baseline request in Repeater
• check cookies, anti-CSRF tokens, and session rules
• confirm whether Burp’s login/session handling is still valid

See examples/review-example.md for a worked operator log showing baseline capture, replay, and evidence notes.

Best Practices

• Do confirm written scope before intercepting or scanning.
  Do not “discover” scope by browsing arbitrary sibling hosts.

• Do use a dedicated browser profile for the assessment.
  Do not mix personal or unrelated corporate traffic into the Burp project.

• Do test one security hypothesis at a time in Repeater.
  Do not change multiple request fields at once if you need defensible comparisons.

• Do maintain valid syntax for JSON, XML, multipart, and form-encoded bodies.
  Do not treat parser failures as evidence of a meaningful security finding without context.

• Do verify authentication continuity before relying on scan output.
  Do not assume a scanner stayed logged in just because the run completed.

• Do prefer targeted scans on selected requests or branches.
  Do not launch broad scans against production-like systems without explicit approval.

• Do compare response code, body, headers, and side effects.
  Do not judge results from status code alone.

• Do capture enough evidence to reproduce the finding later.
  Do not store secrets in notes longer than necessary; redact or minimize where possible.

Troubleshooting

Symptoms: Burp shows little or no application traffic.
Solution: Verify browser proxy settings, Burp listener configuration, and certificate trust. Make sure the app is actually using the proxied browser and not a separate device or native client.

Symptoms: Requests appear, but authenticated pages collapse back to login during replay or scanning.
Solution: Re-capture the login flow, confirm cookie/token freshness, check anti-CSRF handling, and validate that the baseline request still works in Repeater before continuing.

Symptoms: Many findings target redirects, logout paths, or generic error pages.
Solution: Review scope selection and scan targeting. Remove low-value branches, confirm session continuity, and re-run only the relevant authenticated locations.

Symptoms: Modified requests return parser errors instead of business-logic differences.
Solution: Keep the original request structure intact. Change only the field under test and preserve content type, encoding, delimiters, and required fields.

Symptoms: The application behaves differently than expected under HTTP/2 or API testing.
Solution: Confirm the protocol path and endpoint behavior you are actually exercising. Compare the live browser request to the Repeater request and check whether headers, pseudo-header behavior, or transport assumptions changed.

Symptoms: Scanner activity causes lockouts, rate limiting, or unstable sessions.
Solution: Stop or narrow the scan, document the safety event, lower request volume if allowed, and resume only after confirming approved limits with the owner.

Additional Resources

• references/review-criteria.md — open this when you need a compact review matrix for scope control, session-aware testing, HTTP/API checkpoints, and stop/escalate decisions.
• examples/review-example.md — open this when you want a worked example of request capture, replay, comparison, and evidence writing.
• assets/schema-map.json — open or parse this when dealing with API payload types, auth placement, and replay cautions for common request patterns.

Related Skills

No related local skills were provided in the source context.