What Burp Suite Results Include
Knowing how to check results in Burp Suite starts with understanding where those results come from.
Burp Suite can generate findings from passive scanning, active scanning, manual testing, comparisons, and captured HTTP traffic, so the output is more than a simple list of vulnerabilities.
Results may appear in the Dashboard, Scanner, Issue activity, Site map, Target, Proxy, and HTTP history tabs, depending on the edition and workflow you use.
The key is learning which view shows raw evidence, which view shows detected issues, and which view helps you verify whether a finding is real.
Where to Check Results in Burp Suite
The most efficient way to review Burp Suite output is to move from summary views to evidence views.
This lets you see which alerts matter, then validate them with request and response data.
Dashboard
The Dashboard gives you a high-level view of ongoing activity.
In Burp Suite Professional, it typically shows live scan status, task progress, issue counts, and alerts across the current project.
Use it first to see whether scans are running, paused, or complete.
Scanner and Issue Activity
The Scanner area is where Burp Suite groups discovered issues by severity and confidence.
Each item usually includes a short description, affected URL, issue detail, and remediation guidance.
The Issue Activity panel helps you track newly identified issues and understand how they change over time.
Target and Site Map
The Target tab and Site map are useful for browsing the application structure.
They show discovered hosts, directories, endpoints, parameters, and content types.
If you are checking results after a test, this is where you confirm that Burp actually reached the right pages and parameters.
Proxy and HTTP History
The Proxy history is essential for reviewing captured traffic.
It shows every intercepted request and response that passed through Burp, making it useful for checking manual test results, replayed requests, and authentication flows.
HTTP history is often the best place to inspect whether a request caused a change in behavior, status code, or response body.
How to Check Results in Burp Suite Step by Step
If you want a reliable workflow, start broad and then drill down into evidence.
This reduces false positives and helps you separate informational noise from actionable security issues.
- Open the Dashboard and confirm that scans or tasks have completed.
- Review the issue summary by severity and confidence.
- Open each issue to read the description, affected location, and evidence.
- Check the request and response to see what triggered the finding.
- Use the Site map or Target tab to verify the endpoint, parameter, or host.
- Reproduce the behavior manually if the result appears questionable.
This process is especially important when working with dynamic applications, where a single response code or reflected parameter does not always indicate a vulnerability.
How to Interpret Burp Suite Issues
Burp Suite classifies findings using severity and confidence.
Severity indicates potential impact, while confidence reflects how sure Burp is that the issue exists.
Reading both values together is important because a high-severity issue with low confidence may require manual validation before it is reported.
Severity Levels
- High: Likely to create serious security impact, such as authentication bypass, remote code execution indicators, or critical injection behavior.
- Medium: May allow meaningful abuse, such as session weaknesses, information disclosure, or some forms of injection.
- Low: Usually indicates limited impact, such as weak headers, minor misconfigurations, or low-risk exposure.
- Information: Useful context only, often related to technologies, page behavior, or non-vulnerable observations.
Confidence Levels
- Certain: Burp has strong evidence supporting the issue.
- Firm: Evidence is strong, but manual verification is still useful.
- Tentative: The result may be a false positive or require deeper review.
When learning how to check results in Burp Suite, always prioritize issues with both high severity and high confidence.
Then move to lower-confidence findings and validate them with additional requests, payloads, or response comparisons.
What Evidence Should You Review?
Good analysis depends on reviewing the exact evidence Burp collected.
Most issue entries include several fields that help you confirm whether the finding is valid.
- Affected URL: Shows the endpoint where the issue was found.
- Issue detail: Explains the behavior Burp observed.
- Remediation detail: Suggests how the issue can be fixed.
- Request and response: Provides the raw HTTP exchange that triggered the finding.
- Insertion point: Identifies the parameter or location where input was tested.
- Evidence: Highlights the specific response content or behavior that supports the issue.
For common vulnerabilities like SQL injection, cross-site scripting, path traversal, or authentication issues, the strongest evidence usually comes from a repeatable change in application behavior.
That may be an altered status code, changed response length, reflected payload, error message, redirect, or access to restricted content.
How to Review Scanner Output More Effectively
Burp Scanner can produce a large amount of output, especially on complex applications.
Instead of reading every item in order, filter and sort the results strategically.
Sort by Severity and Confidence
Start with the highest severity issues that also have strong confidence.
This gives you the fastest path to the findings most likely to matter in a security report or assessment.
Check for Duplicate Findings
Large applications often trigger the same issue on multiple paths or parameters.
Burp may group these separately or together depending on the issue type.
Look for repeated patterns so you do not waste time validating the same root cause multiple times.
Inspect Passive vs Active Findings
Passive findings are based on observed traffic and are less intrusive.
Active findings come from Burp sending test payloads and are more likely to reveal actual weaknesses, but they also require closer review because false positives can still occur.
How to Validate Results Manually
Manual validation is one of the most important parts of checking Burp Suite results.
A scanner can point you to suspicious behavior, but a human reviewer decides whether the behavior represents a real security issue.
- Repeat the request with Repeater to confirm the same behavior occurs consistently.
- Compare baseline and test responses using response length, status code, headers, and content.
- Change one parameter at a time to isolate the cause of the result.
- Review authentication state to determine whether the issue depends on a logged-in session.
- Check browser behavior if the issue involves redirects, JavaScript, or client-side enforcement.
Burp Repeater is especially useful because it lets you resend the exact request and modify it in a controlled way.
That makes it easier to verify whether the scanner correctly identified an issue or merely detected an unusual response.
How to Export or Share Burp Suite Results
If you need to report findings or compare test runs, Burp Suite offers ways to export results for documentation.
In professional workflows, results are often shared as issue reports, project files, or exported summaries for clients and internal teams.
Before sharing, review the output for sensitive data such as session cookies, tokens, personal information, or internal endpoints.
Burp captures real traffic, so exported data may include secrets that should not be distributed broadly.
Common Mistakes When Checking Results
Even experienced testers can misread Burp output if they move too quickly.
Avoid these common mistakes when analyzing findings.
- Assuming every alert is a vulnerability: Some alerts are informational or tentative.
- Ignoring confidence levels: Severity alone does not prove the issue exists.
- Skipping raw HTTP evidence: The request and response often reveal whether the finding is legitimate.
- Missing context from authentication: Some issues only appear for specific roles or sessions.
- Failing to reproduce manually: Validation is essential before reporting.
Burp Suite Editions and Result Visibility
The way you check results in Burp Suite depends partly on the edition you use.
Burp Suite Professional includes the built-in Scanner and richer issue tracking, while the Community Edition focuses more on manual testing and proxy-based analysis.
In Community Edition, you will rely more heavily on the Proxy, Repeater, Intruder, and Site map views to understand what happened during testing.
Regardless of edition, the same principle applies: use the summary view to locate interesting behavior, then inspect the raw traffic to confirm it.
Fast Checklist for Reviewing Results
- Open the Dashboard and confirm scan status.
- Review issues by severity and confidence.
- Inspect affected URLs and parameters.
- Read the request and response evidence.
- Validate suspicious findings in Repeater.
- Use the Site map to confirm endpoint coverage.
- Document only findings you can reproduce.
When you follow this workflow, how to check results in Burp Suite becomes a repeatable process rather than a guess.
That makes it easier to spot real vulnerabilities, reduce false positives, and produce cleaner security reports.