Unit 10: Capstone: review the shop · Lesson 3 of 4 · 22 min
Deliver the report
Turn the findings into a rated, actionable report and list what the shop already does well.
mission
- You are
- The analyst delivering the shop's review.
- Situation
- The findings are reproduced. Developers will read this once and act from it, so it has to be ranked and specific.
- Goal
- Fill the findings table, rate each item and record the good practices.
- Hand in
- A finished report: findings by severity, fixes and a good-practice list.
How the report is read
- SummaryLeaders read only this
- Findings by severityDevelopers start here
- Good practiceWhat not to break
- EvidenceCommands and outputs
Write the summary line
grep -cE '^\| F[0-9]' report-template.md
1
you should see One placeholder row, ready for your findings.
A weak finding versus a strong one
The API is insecure.
No location, no severity, no fix.
High: /api/orders reflects any Origin with Allow-Credentials: true. Fix: allowlist known origins.
A developer can act on it today.
Rank by severity
The findings table in the lab on the right holds the full review. Sort it by severity and read the high items first.
you should see Five high findings, all about auth and access control.
defender tip Lead with the findings that let someone read another person's data or act as them. Headers and HSTS matter, but they are not what gets an account taken over.
Record what is already good
Open the Good practice tab. A review that only lists faults gets ignored; naming what works builds trust and tells the team what not to break.
you should see Six practices worth keeping, from PBKDF2 to the Origin check on email changes.
What a defender takes away
- 1Rank findings by impact, not by the order you found them.
- 2Each finding names where it is, how bad it is and the fix.
- 3List good practice too, so the team keeps it.
Questions
0 of 3 solved
Answer each one from what you find on your lab machine.