Writing a good security report

Understand the purpose of a security report

A security report communicates a verified security weakness to the people responsible for assessing and fixing it. A strong report explains what is vulnerable, how the issue can be reproduced, what an attacker can achieve, and why the result matters.

Your goal is to make independent verification straightforward. The reviewer should not have to guess which asset you tested, reconstruct missing steps, or infer the impact from an unexplained screenshot.

A technically interesting observation is not automatically a valid vulnerability. Distinguish unexpected behavior from a demonstrated security boundary violation, and explain the evidence connecting the two.

Keep the report focused on one underlying vulnerability whenever possible. If several observations share the same root cause and can be addressed together, explain their relationship. If they represent independent weaknesses with different remediation requirements, consider separate reports according to the program's submission rules.

Start with a precise title

Describe the vulnerability class, affected component and demonstrated impact in one concise sentence. The title should help a reviewer understand the issue before opening the full report.

A useful pattern is: '[Vulnerability class] in [component] allows [specific impact].' For example, 'Broken object-level authorization in invoice endpoint exposes another user's invoice.' Use examples only when they accurately describe your finding.

Avoid vague titles such as 'Security issue', 'Critical bug', 'Possible exploit' or 'Website vulnerable'. They do not communicate what failed or why it matters.

Do not use a severity label as a substitute for describing the vulnerability. Avoid words such as 'critical', 'complete compromise' or 'zero-day' unless the terminology is justified and relevant.

If the root cause or impact is not yet fully established, use a narrower title that accurately describes the observed behavior. Update the title if triage establishes a more precise classification.

Identify the affected asset

Name the exact in-scope asset where the issue occurs. Depending on the program, this may be a domain, subdomain, API, application, mobile app, repository, service or specific product component.

Include the relevant endpoint, HTTP method, application route, feature name or component version when known and useful. Avoid listing unrelated assets simply because they belong to the same organization.

Confirm that the affected asset is covered by the program at the time of testing. A vulnerability on an unlisted third-party service, vendor system or unrelated domain may fall outside the program's authorization.

If the issue depends on a particular account role, subscription level, tenant, configuration or application version, state that dependency explicitly.

If the same root cause affects multiple in-scope assets, list the verified affected assets and explain how you confirmed that they share the same vulnerability. Do not assume that untested assets are affected.

Write a concise summary

Begin with a short summary that identifies the weakness, the affected functionality and the main security consequence. A reviewer should understand the core issue without reading every technical detail.

Explain the vulnerable behavior rather than merely naming a vulnerability category. For example, state that the server accepts an object identifier belonging to another user without checking ownership, rather than writing only 'IDOR found'.

Include the most important preconditions, such as the need for an authenticated account or a specific user role. This helps the reviewer understand the actual attack scenario.

Keep speculation separate from confirmed results. If you suspect a broader impact but have not verified it, label it as a possibility and explain what remains unconfirmed.

Avoid repeating the entire reproduction procedure in the summary. Put the detailed sequence in the reproduction section.

Explain the vulnerability and root cause

Describe what the application does incorrectly and which security expectation it violates. Where possible, identify the missing authorization check, incorrect validation, unsafe trust assumption, exposed resource or other relevant behavior.

Explain the difference between the expected secure behavior and the observed behavior. For example, a server should verify that the authenticated user is authorized to access a requested object before returning its contents.

Distinguish the observable symptom from the underlying cause. An unexpected response may indicate a problem, but the report should explain why that response demonstrates a security weakness.

Do not claim to know the internal implementation if you have only observed external behavior. Describe the behavior you verified and identify any root-cause explanation as a hypothesis when it has not been confirmed.

If the issue depends on a sequence of actions, explain why the order matters and which step creates the security impact.

Describe the security impact

Explain what an attacker can actually do as a result of the vulnerability. Connect the technical behavior to a concrete consequence for confidentiality, integrity, availability, authorization or business operations.

Identify the security boundary that is crossed. Examples include accessing another user's data, modifying a resource without permission, performing an administrative action as a lower-privileged user, or bypassing an access restriction.

Describe the attacker's required access and preconditions. State whether the attack requires an unauthenticated request, a normal user account, a privileged role, user interaction or another specific condition.

Explain the scope of the demonstrated impact. If you verified access to one test record, do not claim that all customer records are exposed unless the broader claim is supported by evidence.

Separate demonstrated impact from plausible consequences. If a vulnerability could potentially lead to a larger compromise, explain the technical reasoning and clearly identify the unverified part.

Consider realistic abuse scenarios. Explain who could exploit the issue, which assets or users could be affected, and what practical result the attacker could obtain.

Do not equate an unusual response, stack trace, banner or error message with a high-impact vulnerability without establishing a meaningful security consequence.

Use the minimum level of testing necessary to demonstrate the impact. Do not access unrelated accounts, collect unnecessary records or cause disruption merely to make an impact statement appear stronger.

Provide reproducible steps

Reproduction steps should allow an authorized reviewer to verify the same behavior without needing to infer missing actions. Write them in chronological order and assume the reviewer has not seen your testing session.

Use a fresh test state where practical. If the issue requires an existing record, account relationship, application setting or prior action, explain how the prerequisite is established.

Use numbered steps for procedures with multiple actions. Each step should describe one clear action and identify the relevant interface, endpoint, parameter or request.

Specify the account role and relevant test data used. When two accounts are required, label them consistently, such as Account A and Account B, and explain the purpose of each.

Include the relevant HTTP method, endpoint, parameter, header or request body when it materially affects reproduction. Remove unnecessary headers and unrelated details.

Record any required application state, permissions, feature flags or configuration. Do not assume the reviewer knows which settings were enabled during testing.

Explain the exact response or visible behavior that confirms the issue. Include relevant status codes, response fields or UI changes where appropriate.

State the expected secure behavior alongside the actual result. This makes the security failure explicit.

If the result is intermittent, describe the observed frequency, relevant timing or environmental conditions, and any known limitations. Do not present an unreliable reproduction as deterministic.

If the issue could not be reproduced again, disclose that fact and provide the original evidence and conditions. Do not invent steps or claim successful verification.

• Identify the in-scope asset and affected feature.
• Describe the required account, role and starting state.
• List each action in the exact order needed to reproduce the issue.
• Include the minimum relevant requests, responses or screenshots.
• State the observed result and the expected secure result.
• Explain the security impact demonstrated by the reproduction.
• Document any limitations, dependencies or intermittent behavior.

Include useful HTTP request and response evidence

For web and API vulnerabilities, raw HTTP evidence can be more useful than screenshots alone. Include the relevant request and response when they help demonstrate the security failure.

Preserve the method, path, relevant parameters, content type, required non-sensitive headers and response fields. Include a status code and a short explanation of why the response matters.

Remove or redact session cookies, bearer tokens, API keys, passwords, private keys, authorization headers and other secrets before submission. Do not assume that a report attachment is safe merely because it is visible only to program participants.

Replace sensitive identifiers and personal data with clear placeholders where possible. Keep the structure needed to understand the issue while removing unrelated information.

If you modify a request to demonstrate the vulnerability, identify the meaningful change. For example, explain that an object identifier was changed from a test record owned by Account A to a test record owned by Account B.

Avoid attaching entire proxy histories, browser profiles or large log files when a small, focused excerpt proves the finding. Unnecessary data increases review time and the risk of exposing secrets.

If request and response examples are edited, redact only information that is not necessary to reproduce or understand the issue. Do not alter the evidence in a way that misrepresents the observed behavior.

Use synthetic records and accounts controlled by you whenever possible. If real user data appears unexpectedly, stop unnecessary access, preserve only the minimum evidence permitted by the program, and follow its sensitive-data handling instructions.

Use screenshots, recordings and attachments effectively

Use screenshots when they clarify an application state, user-visible impact or sequence that is difficult to communicate in text. A screenshot should support the reproduction steps rather than replace them.

Capture the relevant area clearly and include enough context to identify the feature or result. Avoid cropping away details that are necessary to understand what happened.

Redact credentials, tokens, personal data, private messages, unrelated browser tabs and other sensitive information before uploading evidence.

Use annotations sparingly to identify important fields or behavior. Annotations must not obscure the underlying evidence or imply a result that was not observed.

For videos or recordings, keep the sequence short and focused. Explain what the recording demonstrates and include written reproduction steps as well.

Use descriptive attachment names, such as 'authorization-failure-response.txt' or 'reproduction-step-3.png', instead of generic names such as 'image1.png'.

Check that attachments open correctly and do not contain hidden sheets, embedded credentials, unrelated documents or unnecessary metadata.

Do not upload malware, destructive payloads, confidential third-party material or large data dumps unless the program explicitly permits the material and it is necessary for verification.

Provide minimal and sufficient evidence

Evidence should establish the finding with the smallest practical amount of data. More data does not automatically make a report more convincing.

Prefer a small number of clear requests, responses, screenshots or controlled test records over a large archive of unrelated output.

Use test accounts and synthetic data to demonstrate cross-account access, privilege boundaries or data exposure wherever possible.

Do not download an entire database, enumerate large sets of users or access unrelated records to estimate the full scale of an issue. Demonstrate the security boundary violation with the minimum permitted proof.

If the issue exposes sensitive data, describe the type of information and the verified access path without unnecessarily reproducing the information itself.

Explain how each attachment supports a specific claim. Remove duplicate evidence and unrelated debugging material.

Keep original evidence securely in accordance with the program's rules and applicable retention requirements. Do not retain sensitive copies indefinitely or distribute them to people who do not need access.

Explain severity without inflating it

Severity should reflect the demonstrated security impact, exploitability, required privileges, attack conditions and the program's published rating criteria.

Describe the technical facts that influence severity. These may include whether exploitation is remote, whether authentication is required, which privileges are needed, what information or functionality is affected, and whether user interaction is necessary.

If you provide a CVSS score, identify the CVSS version and include the vector where applicable. Explain assumptions that materially affect the score.

Do not treat a CVSS score as a guaranteed program outcome. Organizations may apply their own severity policy, business context, asset classification and program-specific exclusions.

Do not claim account takeover, arbitrary code execution, administrative access, sensitive data exposure or service-wide compromise unless the evidence supports the claim.

A vulnerability can be valid even when its severity is low. Report the verified weakness accurately rather than overstating impact to seek a higher reward.

If the final severity depends on an unverified condition, state the condition and explain what evidence would be needed to establish it.

Avoid assigning a severity rating solely because a vulnerability class is commonly associated with a particular rating. The actual implementation and demonstrated consequences matter.

Explain the attack scenario

When the finding requires multiple conditions, describe the attack path from the attacker's initial position to the demonstrated outcome.

Identify the attacker's starting privileges, the vulnerable operation, any required victim interaction and the final security consequence.

For chained vulnerabilities, explain each step and show how the steps combine to produce an impact that would not exist from the individual observations alone.

Do not combine unrelated weaknesses into a hypothetical chain without evidence that the chain is technically feasible under the program's conditions.

If exploitation requires a particular configuration or account relationship, state that dependency prominently. A reviewer should not have to discover it during triage.

Use a concise attack narrative rather than an unnecessarily elaborate hypothetical scenario. Focus on what the evidence establishes.

Explain common vulnerability classes accurately

For broken access control or IDOR, identify the protected object or operation, the caller's privileges, the authorization check that appears to be missing, and the unauthorized result. Use controlled accounts and records wherever possible.

For authentication weaknesses, explain which authentication requirement can be bypassed or weakened and what access becomes possible. Distinguish a login-flow issue from a demonstrated ability to impersonate another user.

For cross-site scripting, describe the injection context, the affected origin, the conditions required for execution and the actual security consequence. Do not assume that every reflected input or HTML injection proves script execution.

For SQL injection or command injection, provide the minimum safe evidence that distinguishes injection from ordinary input handling. Avoid destructive queries, unnecessary extraction of data or commands that affect systems outside the authorized test.

For server-side request forgery, explain how the server processes the controlled input and which destination or trust boundary can be reached. Do not probe internal services or cloud metadata endpoints unless the program explicitly permits that testing.

For file upload or path traversal issues, identify the relevant validation or access restriction and demonstrate the permitted impact without uploading dangerous files or accessing unrelated sensitive files.

For business-logic flaws, describe the expected business rule, the sequence that bypasses it and the verified consequence. A surprising workflow result is not automatically a security vulnerability.

For information disclosure, identify the information category, the access boundary and why the exposure matters. Redact the actual sensitive content where possible.

For denial-of-service findings, follow the program's explicit testing limits. Do not perform disruptive tests unless they are expressly authorized and adequately controlled.

These examples are reporting guidance, not authorization to perform every technique. The specific program scope and Rules of Engagement determine which tests are permitted.

Explain the expected secure behavior

State what the application should do under the same conditions if the vulnerability were not present.

For authorization issues, this may mean denying access to an object the authenticated user does not own or lack permission to view.

For input validation issues, describe the relevant validation or safe handling expected at the appropriate trust boundary.

For business-logic flaws, explain the invariant or rule that should remain true, such as preventing a user from applying the same benefit multiple times when the rules allow it only once.

Keep expected behavior grounded in observable product behavior, documented requirements or established security principles. Do not invent undocumented business requirements.

If the intended behavior is unclear, explain the ambiguity and ask the program owner to clarify rather than presenting an assumption as a confirmed specification.

Discuss possible root causes and remediation

When useful, provide a concise explanation of the likely root cause and the security control that should address it. The purpose is to help the organization understand and fix the issue, not to prescribe an entire redesign.

For authorization weaknesses, recommend enforcing server-side authorization for every relevant object and operation, using the authenticated identity and the intended access policy.

For injection vulnerabilities, recommend using context-appropriate output encoding, parameterized queries, safe APIs or other controls that match the actual injection context.

For sensitive information exposure, consider access controls, response minimization, secret management and removal of unnecessary sensitive fields from client-visible responses.

For business-logic weaknesses, identify the invariant that must be enforced server-side and any concurrency or state-transition conditions that matter.

Treat remediation suggestions as recommendations rather than confirmed descriptions of the organization's architecture. You may not know which framework, service or internal control is responsible.

Do not require a specific implementation if multiple approaches could correctly address the root cause. Focus on the security property that must be restored.

If you do not know the root cause, provide the observed failure and a reasonable remediation direction without presenting speculation as fact.

Keep the report focused and technically precise

Use direct language and define uncommon technical terms when they are important to understanding the issue. Avoid long introductions, marketing language and repeated explanations.

Separate facts, assumptions and recommendations. A reviewer should be able to tell which statements were directly observed and which are interpretations.

Use consistent names for accounts, endpoints, parameters and resources throughout the report. If you use placeholders, explain what each placeholder represents.

Avoid unexplained acronyms, oversized blocks of raw output and irrelevant background about your research process.

Do not include unrelated security observations simply to increase the apparent size of the finding. Keep each claim connected to the reported vulnerability.

Proofread for contradictions between the title, impact, severity, reproduction steps and evidence. For example, do not describe an issue as unauthenticated if your reproduction requires a logged-in session.

Prefer precise statements such as 'Account A can retrieve the synthetic invoice belonging to Account B' over broad claims such as 'All user data is exposed' when only one controlled record was verified.

Avoid common reporting mistakes

• Submitting a vulnerability title without explaining the security impact.
• Reporting a scanner alert without manual validation or sufficient supporting evidence.
• Providing reproduction steps that omit required account roles, parameters or starting conditions.
• Claiming a worst-case consequence that has not been demonstrated.
• Assigning severity based only on the vulnerability category.
• Submitting an out-of-scope asset or ignoring the program's testing restrictions.
• Attaching raw logs, proxy exports or screenshots that contain secrets or unnecessary personal data.
• Using evidence from unrelated accounts or third-party systems without authorization.
• Combining several independent issues into one report without explaining their relationship.
• Submitting multiple reports for the same underlying root cause without checking the program's duplicate policy.
• Treating a theoretical weakness, informational observation or hardening recommendation as an exploitable vulnerability without a demonstrated security consequence.
• Continuing testing after obtaining sufficient proof, particularly when further activity could expose data or disrupt a service.
• Publishing the finding or contacting affected users outside the program's disclosure rules.
• Arguing about severity before providing the technical evidence needed to assess it.

Check for duplicates and related findings

Before submitting, review your own notes and any program information available to you for reports describing the same underlying issue.

Two endpoints or parameters may share a common root cause. Conversely, similar symptoms may arise from different weaknesses and require independent fixes.

If a related report already exists, follow the program's duplicate and disclosure rules. Do not attempt to access another researcher's confidential report or private evidence without permission.

When submitting multiple related findings, explain the distinct security boundaries, root causes or remediation requirements that justify separate reports.

Do not split a single vulnerability into artificial reports solely to seek multiple rewards, and do not merge independent vulnerabilities in a way that obscures their separate impacts.

Handle sensitive data responsibly

A vulnerability report may contain information about users, systems, credentials or internal operations. Include only what is necessary for verification and follow the program's instructions for handling sensitive material.

Never place live passwords, session tokens, private keys, API secrets or other reusable credentials in the report unless the program explicitly requires a controlled secret-handling procedure. Prefer redacted values and explain the role of the omitted value.

If you accidentally encounter real personal data or confidential records, stop unnecessary access and do not expand collection to measure the full exposure.

Do not copy, retain, redistribute or use exposed data for unrelated purposes. Follow the program's incident instructions and applicable requirements for reporting accidental exposure.

Before attaching evidence, review screenshots, HTTP history, browser storage, source files, archives and document metadata for unrelated sensitive information.

Use the program's approved submission channel. Do not send sensitive evidence through unrelated public channels, personal social media or public issue trackers.

If evidence cannot be safely uploaded through the available submission mechanism, explain the limitation and ask the program owner for an approved alternative.

Submit through the correct program workflow

Confirm that the report is being submitted to the organization and program responsible for the affected asset. A valid technical finding may be delayed or rejected if it is sent to the wrong recipient.

Review the program's current scope, exclusions, severity policy, reporting instructions and disclosure requirements before submitting.

Complete any required fields accurately. If the platform requests a title, summary, impact, reproduction steps, severity or attachments, ensure that each field contains the appropriate information.

Do not assume that saving a draft, discussing a finding in a team session or sharing evidence with teammates constitutes an official report submission.

Keep a copy of the report reference or confirmation when the platform provides one. Use the official report thread for follow-up communication whenever possible.

If the submission process fails, preserve the error details without exposing sensitive report content publicly and use the program's stated support route.

Respond to triage questions

Treat reviewer questions as requests to clarify or verify the finding. Answer each question directly and provide only the evidence needed to resolve the uncertainty.

If a reviewer cannot reproduce the issue, check whether the report omitted a prerequisite, account role, configuration, request header or application state.

If you discover that a statement in the original report was inaccurate, correct it promptly. Explain the correction and its effect on the demonstrated impact or severity.

Do not invent additional evidence, alter results or claim a reproduction succeeded when it did not.

If further testing is needed, confirm that the proposed activity remains within the program's authorization and testing limits before proceeding.

Keep the discussion professional, concise and focused on technical facts. Disagreement about severity or validity should be supported by reproducible evidence and the applicable program criteria.

If the program requests information that could expose unrelated sensitive data or require testing beyond the original authorization, clarify the request and agree on an appropriate method before proceeding.

Handle retesting and remediation verification

When an organization reports that a fix has been deployed, verify the original behavior again only if retesting is permitted by the program.

Use the same controlled prerequisites and reproduction sequence where practical. Record whether the original attack path still succeeds, is blocked, or has changed.

A successful retest should demonstrate the relevant security property, not merely a different response code or changed interface.

If the original issue is fixed but a related weakness remains, document the remaining behavior precisely and follow the program's process for reopening or submitting a related finding.

Do not broaden the retest into unrelated security testing unless the program permits it. A remediation check does not automatically authorize testing every neighboring feature.

If you cannot verify the fix, state the limitation rather than declaring the issue resolved or unresolved without sufficient evidence.

Understand report outcomes

A program may accept, reject, mark as duplicate, request more information or assign another outcome according to its workflow. The exact statuses and their meanings depend on the platform and program.

An accepted report generally means that the organization considers the finding valid under the applicable criteria. It does not necessarily mean that remediation is complete or that a reward is guaranteed.

A duplicate outcome may indicate that the same underlying issue was already reported. Review the program's rules before interpreting the outcome as a judgment about the technical quality of your research.

A request for more information usually means that a reviewer needs additional context, a clearer reproduction or better evidence. Address the specific gap rather than resubmitting the same explanation unchanged.

A rejection may reflect scope restrictions, insufficient impact, non-reproducibility, a program exclusion or another stated reason. Review the explanation and identify whether new evidence can resolve the issue.

If you believe an outcome is incorrect, use the program's established clarification or appeal process where one is available. Keep the discussion factual and reference the relevant program criteria.

Do not assume that every program uses identical status names, reward rules, response times or appeal procedures.

Protect confidentiality after submission

Treat submitted reports, reviewer discussions and supporting evidence as confidential unless the program explicitly states otherwise.

Do not publish reproduction details, screenshots, affected endpoints, internal communications or exploit code before the required disclosure conditions are met.

Follow the specific program's disclosure policy, including any approval requirements and coordinated disclosure arrangements. Do not assume there is one universal publication deadline for every program.

If you want to use a finding in a portfolio, talk, article or public write-up, confirm which details may be disclosed and obtain any required permission.

Remove confidential information from presentations, source repositories, public issue trackers and shared research notes before making them public.

Keep in mind that an accepted report, a deployed fix or the passage of time does not automatically grant permission to disclose the vulnerability.

A practical report structure

Use the following structure as a starting point when the program does not prescribe a different template. Adapt it to the vulnerability and the platform's required fields.

• Title: A concise description of the vulnerability and demonstrated impact.
• Affected asset: The exact in-scope domain, endpoint, application, component or feature.
• Summary: A short explanation of the weakness and the security boundary affected.
• Prerequisites: Required account roles, permissions, configuration and starting state.
• Steps to reproduce: Numbered actions in the correct order.
• Observed result: The actual behavior, with relevant requests, responses or screenshots.
• Expected result: The secure behavior that should occur under the same conditions.
• Impact: The verified consequence, attacker capabilities and meaningful limitations.
• Severity: The program's applicable rating and supporting technical rationale, if requested.
• Evidence: Minimal, redacted attachments that support the claims.
• Remediation guidance: A concise suggestion where it helps the organization address the root cause.
• Limitations: Any unverified assumptions, intermittent behavior or conditions that affect the finding.

Final review checklist

• The title identifies the actual vulnerability and does not exaggerate impact.
• The affected asset is explicitly identified and confirmed to be in scope.
• The summary explains the security weakness in plain technical language.
• The attacker model, prerequisites and account roles are documented.
• The reproduction steps are complete, ordered and independently understandable.
• The observed and expected behaviors are clearly distinguished.
• The impact is supported by evidence and includes relevant limitations.
• The severity rationale follows the program's criteria.
• Requests, responses, screenshots and attachments contain no unnecessary secrets or personal data.
• The evidence is sufficient to verify the issue without collecting unrelated information.
• The report does not combine unrelated findings or duplicate the same root cause unnecessarily.
• Any root-cause analysis and remediation advice are appropriately qualified.
• The report follows the program's scope, submission, confidentiality and disclosure requirements.
• All attachments open correctly and support specific statements in the report.
• The report has been proofread for accuracy, clarity and contradictions.

The principle of a strong report

A strong security report is accurate, reproducible, proportionate and actionable. It gives the organization enough information to understand the vulnerability, verify its impact and choose an appropriate fix.

Technical depth is valuable when it supports a clear conclusion. Unsupported assumptions, exaggerated severity, unnecessary data collection and incomplete reproduction steps make a report harder to trust.

Prioritize verified facts, minimal evidence, clear reasoning and responsible communication. A precise report is more useful than a dramatic claim that cannot be independently reproduced.