Write a Reproducible Security Bug Report

A security bug report is useful when another person can reproduce the behavior and understand its impact. A dramatic title or an AI-generated explanation cannot replace that evidence. Start with the smallest authorized test that demonstrates the issue, then document exactly what you observed.

This workflow is for your own application, a permitted test environment or a program whose published scope authorizes the activity. It focuses on report quality and defensive remediation. Don't extend testing into unrelated accounts or infrastructure to make the report sound more serious.

Confirm scope before collecting evidence

Record the permitted asset, account type and testing restrictions. If a program forbids automated scanning or accessing other users' data, respect those limits. A clear report can use test accounts and synthetic records to show a boundary failure without collecting real private information.

Write down the environment and date. Include the application version if available, the browser or client version and whether the test used a staging or production service. These details help a reviewer distinguish a current issue from an already fixed behavior.

Describe expected and observed behavior

Use plain language. For example: a viewer account should be unable to edit a project name, but the authorized test account could submit a change through the project's update endpoint. That statement identifies the permission boundary and the action.

Avoid beginning with a vulnerability category unless you have demonstrated that category. OWASP's vulnerability reference can help with terminology, but a category name does not establish that your particular application is affected.

Separate observation from inference. If you changed one test record, report that. If you believe a wider set of records could be affected, label it as a hypothesis and explain what additional authorized evidence would be needed.

Create a minimum reproduction

Provide a numbered sequence with necessary setup, the exact operation and the result. Remove unrelated browser actions. Use stable synthetic identifiers that a reviewer can create themselves, rather than assuming access to your personal session.

An illustrative evidence object might look like this:

{
  "environment":"authorized-staging",
  "actor_role":"viewer",
  "operation":"update_test_project_name",
  "expected":"denied",
  "observed":"change persisted"
}

Review a sanitized copy in the JSON Viewer. Keep tokens, session cookies and private identifiers out of the report. Redaction must preserve the relationships necessary to understand the test, such as which account owns which synthetic resource.

Prove persistence and impact

A success-looking HTTP response is not always proof that a change occurred. Read the test resource again through a separate authorized path. Show the before and after state, including whether the change survives a refresh or a new request.

Use JSON Diff for sanitized response objects. Highlight the meaningful changed field rather than including a large unrelated payload. If the response contains timestamps or generated request IDs, explain why they aren't part of the evidence.

Describe impact in terms of the demonstrated action: unauthorized editing of a test resource, disclosure of a synthetic field or bypass of a specified restriction. Don't claim complete account takeover from an unrelated minor error. Keep the severity assessment proportional to the evidence.

Include useful negative controls

A good reproduction often includes one comparison that should behave differently. Show that the owner can perform the action and that the viewer is expected to be denied. Alternatively, demonstrate that a correctly scoped resource is accepted while an out-of-scope synthetic resource is rejected.

Negative controls prevent confusion about normal application behavior. They can also reveal that the apparent vulnerability was actually a test account with broader permissions than expected. Check account roles immediately before the test rather than relying on a remembered setup.

Keep these comparisons small. A report isn't stronger because it contains hundreds of nearly identical requests. Once the boundary failure is demonstrated within scope, stop and explain it.

Use AI assistance carefully

An assistant can improve wording, organize reproduction steps or identify missing environment details. Require it to preserve observed facts and distinguish them from suggested interpretations. Verify every generated command, endpoint and version claim before including it.

Don't let the assistant invent exploitability or a vendor response. If a suggested test goes beyond authorized scope, exclude it. A report that admits a limitation is more useful than one that hides uncertainty behind confident language.

Use Markdown Preview to check headings and code blocks. Ensure that the report still makes sense without screenshots; text steps should carry the reproduction, while images support specific observations.

Give remediation direction without prescribing blindly

Describe the control that appears missing and where it should be enforced. For a permission issue, that may be server-side authorization tied to the current actor and resource. The application's maintainers decide the implementation details.

Offer a verification condition: the same synthetic request should be denied, legitimate owner behavior should still work, and the test record should remain unchanged. This provides a useful acceptance test for the fix without assuming a particular framework.

Conclusion

A strong security report contains authorized scope, a minimum reproduction, a verified state change and a precise impact statement. Keep speculation separate, remove secrets and include a small control comparison. Clear evidence makes triage and remediation faster than inflated severity language.