# A vulnerability report example, with notes

One bug in a practice shop, written up the way I ask my students to, with notes on each part.

A good vulnerability report lets a stranger repeat what you did, see what you saw and know what to change. They can't watch you or ask you in a hallway, so your words have to do all of it.

Below is a report for one bug, with notes under each part. I wrote it for this page. It isn't student work, and all of it is made up. moonmart is a practice shop built to be broken, and nothing in it is real.

You only test where you have permission. The rules here: only test the lab, no real sites, use a harmless proof, and stop once you've proven it.

The report uses the seven prompts my students fill in for every finding, on one page. Other reports call the same parts a summary, reproduction steps, observed results, impact and a fix.

## What's the bug, and where is it?

> **Title:** Changing the price in the checkout request changes what you pay
>
> **Target:** moonmart checkout (moonmart.lab/checkout)

This is the summary. A few words that say what breaks and where, so a developer knows what to open before they read anything else. "Checkout bug" wouldn't tell them that.

A request is what the page sends to the server, and the server is the part of the app that handles the order.

## How bad is it, and who does it hurt?

> **Severity, and why:** High. Anyone using the checkout could set their own price, and the shop would lose the difference on every order. I only tested the sticker pack, so the rest of the shop is a guess.

This is the impact, and it's your judgment. Pick low, medium, high or critical, then say what happens and who it hurts. The reason matters more than the level you pick.

The last sentence is there on purpose. It tells the reader where what I saw ends and what I'm inferring starts.

## Can a stranger repeat it?

> **What I did:**
>
> 1. Put the sticker pack ($4.00) in the cart.
> 2. Turned on X-ray and found a hidden field called `price`, set to 4.00.
> 3. Changed `price` to 0.01.
> 4. Pressed Buy.

These are the reproduction steps. Number them, and say exactly what you changed and what you changed it to. Leave out anything that didn't matter, like the ideas that went nowhere.

X-ray is the lab's tool for showing what the page is hiding. A hidden field is a value the page holds and sends but doesn't show on screen.

A screenshot of the request next to the reply is good evidence. If you attach one, the steps still have to work without it.

## What did you actually see?

> **What happened:** The order went through. The page said "Order placed. Total: $0.01." The sticker pack costs $4.00, so the shop should have charged $4.00.

Only what you saw goes here, plus what should have happened instead. Anyone can check this part by repeating your steps.

There's nothing here about other customers, lost money or other products. Those went under severity, because they're what I think the result means. If a developer disagrees with my severity, what I saw still stands.

## Why did it happen?

> **Why it works:** The shop assumed the price coming back from the page was the one it set. Hiding the price on the page didn't stop me changing it.

Name the assumption the app made and why it was wrong. "It's a bug" doesn't count.

## What's the fix?

> **The fix:** Look the price up in the database and ignore the one the page sends.

Say what the server should do instead, in plain English. You don't have to write code. "Add more security" doesn't count either.

## Is this a vulnerability assessment report?

No. This is a single finding: one bug on one page, written so someone can go fix that bug.

A vulnerability assessment report covers everything someone agreed to have tested. It says what was in scope, how it was tested, what turned up and what to fix first, with a finding like this one for each bug.

The closest thing in my course is the week 7 capstone, where students write one report on several bugs in one app. That's still much smaller than a professional assessment.

## What does a weak version look like?

Here are three of the same fields, written badly. This excerpt is made up too.

> **Severity, and why:** Critical. The whole shop is hacked and customer data is at risk.
>
> **What I did:** Changed the price.
>
> **What happened:** It worked.

And written clearly:

> **Severity, and why:** High. Anyone using the checkout could set their own price. I only tested the sticker pack.
>
> **What I did:** Put the sticker pack in the cart, changed `price` from 4.00 to 0.01 and pressed Buy.
>
> **What happened:** The order went through for $0.01 instead of $4.00.

The weak version claims things nobody saw. Nothing in that test went near customer data. "Changed the price" also leaves a developer guessing where, and to what.

## Why stop after one order?

One order proved it, and a second wouldn't tell anyone anything new. Every extra step is one more thing you did to someone's system for no reason.

The [ethics agreement](https://bugclubhq.com/ethics) my students sign says it this way: once you've shown a bug is real, stop. Don't dig further, don't collect anyone's data, don't show it off. Write it up so it can be fixed.

## Check yours before you send it

- Does the title say what breaks and where?
- Could a stranger follow your steps from your words alone and get the same result?
- Did you say exactly what you changed, and what you changed it to?
- Does What happened only have what you saw, and what should have happened?
- Is anything in your severity something you didn't see? If so, did you say it's a guess?
- Did you name what the app assumed?
- Does the fix say what the server should do instead?
- Did you stay in scope and stop once you had your proof?

In my course you write one of these every week, and [I read every one and give you feedback](https://bugclubhq.com/how-lessons-work).

- [All guides](https://bugclubhq.com/learn)
- [The ethics agreement](https://bugclubhq.com/ethics)