Writing a clear and actionable vulnerability report

You have a notebook full of observations. Now comes the part that makes the whole effort useful: turning them into a report that a developer can understand in five minutes and a manager can act on in ten. A vulnerability that is badly explained is a vulnerability that stays open. Professional testers are paid as much for their writing as for their technical skill.

Who reads your report?

Before writing, think about the audience. A typical report has at least three readers with different needs.

A good report layers its content so that each reader can stop reading when they have what they need: a summary at the start, details further on.

The structure of a report

1. Title page and document control. Client, date, version, author, confidentiality level.
2. Executive summary. One page, no jargon: what was tested, the overall result, the most important findings and the recommended next steps.
3. Scope and methodology. What was in scope, the dates, the accounts used, the approach (for example, based on the OWASP Web Security Testing Guide), and limits or constraints. Explaining what was not tested is as important as stating what was.
4. Summary of findings. A table listing all findings with identifier, title and severity, ideally with a count by severity.
5. Detailed findings. One section per finding, using a consistent template (below).
6. Positive observations. Controls that worked well. It is fair and encouraging, and tells the team what to preserve.
7. Conclusion and roadmap. A prioritised list of actions.
8. Appendices. Tools, long evidence, glossary.

Anatomy of a good finding

Use the same template for every finding. Readers learn it once and can scan quickly.

ID:            WEB-003
Title:         Order details accessible by other customers (IDOR)
Severity:      High
Location:      /orders/{id} (training application)
Description:   The application returns an order based on the identifier in
               the URL without verifying that the order belongs to the
               logged-in user.
Impact:        Any authenticated customer can read the name, address and
               purchases of other customers, which exposes personal data.
Steps to reproduce:
  1. Log in as test user A and open order 1042 (belongs to A).
  2. Log in as test user B in another browser profile.
  3. Replay the request for order 1042 with B's session cookie.
  4. Observe that the full order of user A is returned.
Evidence:      Screenshots 3.1 and 3.2 (personal data masked)
Recommendation: Verify on the server that the order belongs to the current
               user at every request; scope the database lookup by owner;
               add an automated test per role.
References:    OWASP Top 10 (Broken Access Control); WSTG access-control tests
Status:        Open

Let us look at each element.

Title

Specific and descriptive: “Order details accessible by other customers” beats “Access control issue”. A reader should understand the problem from the title alone.

Description

Two or three sentences in plain language: what the weakness is and where. Avoid jargon without explanation, and avoid blame.

Impact

The most undervalued part. Describe the consequence, in terms of what an attacker could do and what the organisation would lose: personal data exposed, money lost, accounts taken over, service disrupted, regulatory trouble. Be honest and precise: do not exaggerate to impress, and do not minimise to please. Say what you demonstrated and what you believe is possible, keeping those two things separate.

Steps to reproduce

Numbered, complete, and precise enough for a developer who was not there. Include the accounts, the paths, the parameters and the expected versus the observed result. A good test: could a colleague reproduce the finding using only these steps? If a step is hard to describe, a short screen recording or an annotated screenshot can help. Do not include harmful payloads in the report beyond what is necessary to reproduce the issue; use the safest proof that works.

Evidence

Screenshots, request and response excerpts, log lines. Blur or remove real personal data, credentials and secrets. Evidence should be sufficient to convince, and minimal for the sake of privacy.

Severity

Give a rating, with a short justification. Lesson 2 shows how to use a scoring system consistently.

Recommendation

Concrete and realistic: not “improve security” but “verify ownership on the server for every request to this endpoint”. Indicate a primary fix and, where useful, an interim mitigation (for example a temporary restriction while the full fix is developed). Link to a reference such as the OWASP Cheat Sheet Series, and explain how to verify the fix.

Writing style

• Clear and neutral. Short sentences, active voice. Describe facts, not opinions about the developers.
• Consistent vocabulary. Use the same term for the same thing throughout.
• Define technical terms on first use, or in a glossary.
• Group related issues. If twelve pages lack the same header, write one finding listing them, with one recommendation.
• Distinguish confirmed from suspected. “Confirmed” means you reproduced it; “potential” means you saw indications but could not prove it. Never present a guess as a fact.
• Avoid the exaggerated tone. Dramatic language erodes credibility. Facts, impact and fix are enough.
• Proofread. Check names, paths, dates and numbers. Errors make readers doubt the technical work.

The executive summary

Write it last, but place it first. It should answer in a page: what was tested and when, what is the overall security level, what are the two or three most significant problems and their business effect, and what should be done first. Use plain language and avoid code.

Executive summary (example)
Between 2 and 6 March, we assessed the training web application within the agreed scope.
We found 11 issues: 1 critical, 3 high, 4 medium and 3 low. The most important is
that any logged-in customer can read other customers' orders. Combined with weak
password reset controls, this could lead to account takeover. We recommend fixing
the access control and reset issues first; most other findings can be fixed
through configuration changes. Positive points: injection protection was consistently applied
on the tested forms and session cookies are well configured.

Common mistakes

• A list of tool output pasted without analysis.
• Findings with no impact or no recommendation.
• Steps that cannot be reproduced.
• Everything marked “critical”, so that nothing stands out.
• Leaking sensitive data in screenshots.
• Delivering the report by an insecure channel. Use an encrypted channel agreed with the client.

Your turn: write your first finding

From your testing notebook, choose one confirmed finding from your lab (for instance the SQL injection or the missing session protection) and write it up using the template above. Include a realistic severity, an impact paragraph, reproducible steps and a recommendation with a verification step. Then write a four-sentence executive summary for a fictional report that would contain it.

ID:            WEB-007
Title:         Session cookie missing the HttpOnly attribute
Severity:      Low (rises to Medium if an XSS flaw is present, see WEB-004)
Location:      Session cookie set after login (training application)
Description:   The session cookie can be read by scripts running in the page.
Impact:        If an attacker injects a script through a separate XSS flaw,
               the session could be stolen and reused.
Steps:         1. Log in. 2. Open the browser's storage panel. 3. Observe that the
               cookie has no HttpOnly attribute.
Evidence:      Screenshot 7.1
Recommendation: Set HttpOnly (and Secure, SameSite) on the session cookie.
               Verify by checking the Set-Cookie header after login.

Your report lists findings. Which one should be fixed first? That is the topic of the next lesson.