What a Burp Suite checklist helps you do
If you want consistent web application testing, a checklist turns Burp Suite from a powerful toolkit into a repeatable workflow.
This article explains how to create a checklist with Burp Suite so you can cover the right targets, reduce missed findings, and move through each test in a logical order.
Burp Suite, from PortSwigger, is widely used for manual security testing, proxying traffic, crawling applications, and validating vulnerabilities such as XSS, SQL injection, access control issues, and authentication flaws.
Why a checklist matters in Burp Suite testing
Burp Suite includes many modules, including Proxy, Target, Repeater, Intruder, Decoder, Comparer, and Scanner in Burp Suite Professional.
Without a checklist, it is easy to jump between tools and overlook basic checks like session handling, hidden parameters, or misconfigured headers.
A checklist gives you a stable process for:
- Mapping the application scope
- Capturing relevant requests and responses
- Prioritizing authentication and authorization testing
- Checking input handling and common injection points
- Documenting evidence in a repeatable format
How to create a checklist with Burp Suite
The best way to create a checklist with Burp Suite is to align your list with the application lifecycle: discover, map, test, validate, and report.
Instead of listing only vulnerabilities, structure the checklist around what you need to observe and verify in Burp.
1. Define scope and objectives
Start by recording the application domain, subdomains, environments, and login roles you will test.
Include the test objective, such as OWASP Top 10 coverage, authorization review, or regression testing after a release.
- Target application name and URL
- Environment: production, staging, or QA
- User roles available for testing
- In-scope and out-of-scope paths
- Testing windows and rate limits
2. Configure Burp Suite for the engagement
Before testing, confirm your browser proxy settings, certificate installation, and session handling configuration.
In Burp Suite, verify that traffic is being intercepted correctly and that passive and active features are set according to the engagement rules.
- Proxy listener and browser routing
- Burp CA certificate installation
- Scope settings in Target
- Logging and project file naming
- Extension review in the BApp Store
3. Map the application
Use browsing, Site map, and crawl results to build a reliable inventory of URLs, forms, APIs, and parameters.
This step ensures your checklist is grounded in real application behavior rather than assumptions.
- Main pages and navigation paths
- Forms, uploads, and search functions
- API endpoints and JSON bodies
- Cookies, tokens, and custom headers
- Hidden fields and reference IDs
4. Build a request-focused test list
Burp Suite works best when you test specific requests and responses, not just pages.
Add checklist items for the common places where vulnerabilities appear, and then validate them in Repeater or Intruder.
- Authentication requests
- Password reset and account recovery flows
- Authorization-sensitive endpoints
- Parameter-driven pages
- File upload and import features
- GraphQL, REST, and AJAX calls
Core checklist categories to include
A practical Burp Suite checklist should cover the major security areas seen in modern web applications.
The items below map well to the tools and features inside Burp.
Authentication testing
- Login success and failure responses
- Account enumeration indicators
- Brute-force protections and rate limiting
- Session regeneration after login
- Logout invalidation behavior
Session management testing
- Cookie flags such as Secure, HttpOnly, and SameSite
- Token entropy and reuse
- Idle and absolute session timeout
- Session fixation behavior
- Multi-tab and device logout consistency
Authorization testing
- Horizontal access control checks
- Vertical privilege escalation checks
- IDOR testing on numeric and UUID references
- Forced browsing to restricted endpoints
- Role-based response differences
Input validation and injection testing
- Reflected and stored XSS indicators
- SQL injection error handling
- Command injection opportunities
- Path traversal and file read behavior
- Server-side template injection signs
Business logic testing
- Workflow bypass attempts
- Discount, cart, or payment manipulation
- Race condition-sensitive actions
- Reused tokens or approval codes
- Unexpected state transitions
How to use Burp Suite tools within the checklist
Each Burp module can support a different checklist stage.
The key is to assign a specific purpose to each tool so the workflow stays efficient and measurable.
Proxy
Use Proxy to capture baseline traffic, inspect headers, and identify interesting requests.
Your checklist should include whether interception rules are correct and whether the browser is sending every required request.
Target
Use Target and Site map to organize endpoints by folder, host, and content type.
Add checklist items for verifying completeness of the crawl and identifying unexplored branches.
Repeater
Repeater is essential for manual verification.
Include tasks such as replaying requests with modified parameters, changing cookies, and checking server responses for authorization or validation changes.
Intruder
Intruder helps with controlled payload testing and brute-force style checks where permitted.
Use it for enumeration, fuzzing, and lightweight payload delivery against a known parameter set.
Scanner
If you use Burp Suite Professional, integrate Scanner findings into the checklist, but do not rely on automation alone.
Mark each alert for manual validation, context review, and exploitability assessment.
Extensions
Extensions from the BApp Store can enhance coverage, especially for SAML, JWT, GraphQL, or specific frameworks.
Add a checklist item to review which extensions are approved and needed for the target stack.
Example Burp Suite checklist structure
A good checklist is easy to follow during a live session.
This example format keeps each item specific enough to verify without being overly rigid.
- Scope confirmed: domains, roles, and limits documented
- Proxy validated: browser traffic captured successfully
- Authentication reviewed: login, reset, and MFA flows tested
- Sessions checked: cookies, timeouts, and logout behavior verified
- Access control tested: IDOR and forced browsing attempted
- Inputs tested: key parameters sent to Repeater and Intruder
- Uploads reviewed: file type validation and storage behavior checked
- API endpoints tested: request methods, object IDs, and tokens inspected
- Findings validated: positive and negative tests repeated
- Evidence captured: requests, responses, and screenshots saved
How to keep the checklist practical
The most useful checklist is short enough to use consistently and detailed enough to avoid gaps.
Keep each item action-oriented and tied to a Burp activity, a response pattern, or a security control.
- Use the same structure for every assessment
- Separate discovery items from exploitation checks
- Record role-based results for each important endpoint
- Note whether a finding is confirmed, suspected, or false positive
- Update the checklist after each engagement with new patterns
Reporting items to capture during testing
Your checklist should also support reporting, because documentation is part of the testing process.
When you identify an issue, capture enough detail to reproduce it and explain its impact clearly.
- Request and response pairs
- Affected endpoint and parameter name
- User role used during testing
- Exact payload or modification applied
- Observed result and business impact
- Relevant timestamps and Burp project notes
Common mistakes when building a Burp Suite checklist
Many testers make the checklist too broad or too tool-specific.
A checklist that says “test everything” is not helpful, and a checklist that only lists vulnerabilities may miss the actual steps needed to verify them.
- Relying only on Scanner output
- Skipping role-based access checks
- Ignoring APIs and asynchronous requests
- Failing to document baseline behavior first
- Using vague items that cannot be verified
What a mature checklist should cover over time
As you use Burp Suite across more applications, refine the checklist for technologies you see often, such as JWT, SSO, OAuth 2.0, GraphQL, WebSockets, and microservices APIs.
Over time, a strong checklist becomes a reusable testing asset that improves consistency across teams and engagements.
- Framework-specific behaviors
- Authentication standards like OAuth 2.0 and SAML
- API-specific controls and schema behavior
- Cloud-hosted application patterns
- Regression tests for previously fixed issues