How do I share a Burp Suite report?

Export it from Burp with Target → Site map → Report selected issues, choosing HTML output, then publish that file to Comma. Burp's HTML export is self-contained, so it publishes as a single report body with the request and response evidence intact.

Should I include full request and response evidence?

Include it for the developers who have to reproduce the issue — a finding without the request is a finding that gets disputed. But note that captured requests routinely contain session tokens, API keys and personal data, so the report must be on named-reviewer or domain-gated access, never public.

Why not email the Burp export?

Because it contains working exploitation detail for a live system. An emailed copy cannot be revoked, cannot be audited, and gets forwarded. A published report with an explicit reviewer list can be revoked the moment the engagement ends.

Can developers reply to a specific issue?

Yes. Threads anchor to the rendered content, so the fix, the PR link, or 'this is a false positive because the parameter is server-side validated' lives on the issue instead of in a mail chain.

How do I handle the retest?

PATCH the same report id with the new export. The URL stays stable across the engagement and each export becomes a revision, so the client can see exactly what changed between the initial scan and the retest.

Share a Burp Suite report

Burp's HTML export is genuinely good. Issues grouped by severity and confidence, the remediation guidance, and — the part that makes it useful rather than merely alarming — the actual request and response that demonstrated the issue.

Target → Site map → right-click host → Report selected issues
  → Report format: HTML
  → Include request/response: as applicable
  → Issue detail: full

That evidence is why the report works, and also why sending it is a problem. A Burp export with full request/response detail typically contains:

Session cookies and bearer tokens captured during testing.
API keys in headers or query strings.
Real user data from whatever accounts were in scope.
A step-by-step reproduction of every issue that was found.

And the default distribution channel is an email attachment, which is permanent, uncontrolled and unauditable.

Publish it

Burp's HTML export is self-contained, so it is a single file. Drag it into the app, or POST it:

curl -fsS -X POST "https://commareports.com/api/v1/reports" \
  -H "Authorization: Bearer $COMMA_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d "$(jq -n --rawfile html burp-report.html \
        --arg t "Burp scan — checkout.example.com, 2026-09" \
        '{title: $t, html: $html}')"

Report HTML renders inside a sandboxed iframe (allow-scripts, no allow-same-origin), so Burp's collapsible issue sections and severity grouping behave as they do locally.

Set access before you send the link

This is not optional for this report type. Reports are private by default — keep it that way and choose deliberately:

Named reviewers for a report with unremediated high or critical issues. An explicit list you can see and revoke.
Domain-gated (anyone at client.com) once findings are remediated, or when the client's team is large enough that maintaining a list is friction without benefit.

Never public. See the sharing model.

If the scope of the report is wider than the audience — a full site map export where one team only needs their service — export the subset from Burp rather than publishing everything and asking people to ignore the rest.

Two reports, not one

A pattern worth adopting: export twice.

The technical report — full issue detail, requests and responses, named reviewers, for the engineers doing the fixing.
The summary — issue counts by severity, no evidence, domain-gated, for the people who need to know the state of the system without holding a working exploit guide.

Burp's report wizard supports both from the same scan by varying the issue detail level, and it means the summary can circulate freely without the evidence circulating with it.

Retests

curl -fsS -X PATCH "https://commareports.com/api/v1/reports/$REPORT_ID" \
  -H "Authorization: Bearer $COMMA_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d "$(jq -n --rawfile html burp-retest.html \
        --arg t "Burp scan — checkout.example.com, retest" \
        '{title: $t, html: $html}')"

One URL for the engagement, one revision per scan. The client's bookmark keeps working, and the difference between the initial scan and the retest is a diff rather than two files with dates in the names.

What review adds

Anchored threads per issue — the fix, the PR, or the false-positive argument, on the finding. See commenting on HTML.
Revisions, so remediation is demonstrable rather than asserted.
Revocable access, which is the property an email attachment can never have.

Limits

Entry HTML: 5 MB. A full-detail export of a large site map will exceed this — export by host or by severity band rather than the entire site map, and publish them as separate reports scoped to their audiences.
60 requests/minute per token.

Try it

Comma is free — unlimited reports, unlimited commenters, unlimited revision history.

Publish a report privately →