Audit review and the road to ethical hacking
You have travelled through seven chapters: methodology, authentication, injections, client-side flaws, access control, configuration and reporting. This final lesson brings everything together. You will assemble the findings from your testing notebook into a complete audit deliverable, review what you have learnt, and see how it fits into the broader craft of penetration testing, the subject of the next course in the track.
Before you go further
Everything in this course is for defensive and authorised use. The skills you have learnt are the same ones used by criminals, and what separates a professional from an offender is permission, scope and intent. Keep practising only in your labs and legal platforms, and keep the habit of writing down your authorisation before any test.
Step 1: consolidate your notebook
Open your testing notebook and gather everything in one place. You should have, for your lab application:
- The scope statement and the environment description from chapter 1.
- The inventory of features and entry points, and the role matrix.
- Test results for each family: authentication (login controls, sessions, reset, MFA), injection (SQL and others), client-side (XSS, CSRF, headers), access control and logic (IDOR, escalation, logic, SSRF), and configuration and components (misconfiguration, dependencies, uploads, serialized data).
For each test, you should have a result: vulnerable, not vulnerable, or inconclusive. Keep the “not vulnerable” entries: they show coverage and form the “positive observations” of your report.
Step 2: build the coverage table
A coverage table maps the methodology to what you actually did. It prevents the impression that “nothing found” means “nothing tested”.
| Area | Tests performed | Result |
|---|---|---|
| Authentication | Login controls, enumeration, session cookie, reset, MFA logic | Findings recorded |
| Injection | SQL, command and template reasoning on the lab’s inputs | Findings recorded |
| Client-side | Reflected and stored XSS markers, CSRF, headers | Findings recorded |
| Access control and logic | Two-account IDOR tests, role matrix, assumptions, fetching features | Findings recorded |
| Configuration and components | Errors, exposed files, versions, upload, serialized data | Findings recorded |
Add the date, the versions of the tools and the lab application, and anything that you could not test and why.
Step 3: write the findings and rate them
For each confirmed issue, write a finding sheet with the template from lesson 1 of chapter 7 (title, description, impact, reproduction steps, evidence, severity, recommendation). Rate them with the same method, and write one sentence of justification for each. Group minor issues that share a cause, such as missing headers, into a single finding. Look at the whole set and ask: which findings combine into a more serious chain? For example, a user enumeration flaw plus a weak lockout plus no MFA might together make account takeover realistic. Write the chains in your summary.
Step 4: assemble the report
- Executive summary (one page, plain language).
- Scope and methodology, referencing the OWASP Web Security Testing Guide.
- Summary table of findings with severities.
- Detailed findings.
- Positive observations.
- Prioritised roadmap: immediately, short term, planned, accepted risk.
- Appendices: tool list, glossary, coverage table.
Proofread it, then do a reproduction check: follow your own steps from scratch on a reset lab for at least two findings. Anything you cannot reproduce must be fixed in the report or downgraded to “potential”.
What you can now do
Take stock of your new abilities. After this course you can:
- Explain the phases of a web application test and set up a safe lab with an intercepting proxy.
- Map an application and record its entry points and roles.
- Test authentication, sessions, password reset and multifactor flows, and describe their typical weaknesses.
- Recognise and reason about injection flaws and explain prepared statements and validation.
- Distinguish reflected, stored and DOM-based XSS, CSRF and clickjacking, and propose defences.
- Test access control with a two-account method, think about business logic and understand SSRF.
- Review configuration, components, uploads and serialization risks.
- Write a clear report, rate severity, and explain responsible disclosure.
Be proud, but stay humble. You have learnt the foundations. The craft deepens with every lab and every project.
Common pitfalls for beginners
- Tool-first thinking. Running tools without understanding the traffic. Always understand the request and the response yourself.
- Skipping the notebook. If you did not write it, it will not be in the report.
- Chasing impressive exploits instead of covering the basics. Most real findings come from simple, systematic checks.
- Ignoring scope. The most serious mistake. When in doubt, ask.
- Over-claiming. Report what you proved, and label the rest as potential.
Where this fits in a full penetration test
This course focused on one target type: web applications. A professional penetration test covers more ground and is organised as a complete engagement. The next course of the track, “Ethical hacking: methodology of penetration testing”, widens the view. You will learn how engagements are scoped and contracted, how reconnaissance is conducted on a whole organisation, how networks and systems are assessed, how findings from several areas combine into attack paths using frameworks such as MITRE ATT&CK (at attack.mitre.org), and how a full test is planned, executed and documented. The web skills you just acquired become one module in a larger toolbox.
The final course of the track then helps you turn these abilities into a professional profile: from the test to the polished professional report, plus career paths, certifications and communities. If you enjoyed building your report here, you will feel at home.
Keep growing
- Practise regularly in legal environments: the PortSwigger Web Security Academy (finish the topics matching each chapter), OWASP Juice Shop, DVWA at higher levels, TryHackMe learning paths and, when you are comfortable, HackTheBox.
- Read the references: the OWASP Top 10, the Web Security Testing Guide and the Cheat Sheet Series at owasp.org.
- Follow public security advisories on nvd.nist.gov and the alerts published by national agencies such as ANSSI at cyber.gouv.fr.
- Learn to read code. Many web flaws are obvious in the source. Reading the secure versions of DVWA modules is a good start.
- Share knowledge in communities and write about your learning, respecting confidentiality and legality.
For people around you, you can also make a difference at a basic level: help family and colleagues enable multifactor authentication, update software and recognise phishing. The public resources of cybermalveillance.gouv.fr are a good starting point to share.
Tip
Set yourself a small recurring habit: one lab per week, and one paragraph in your notebook about what surprised you. After six months you will have a personal knowledge base and a portfolio of write-ups (about your own labs) that you can show to a prospective employer.
Your turn: the final deliverable
Produce your complete audit report for your lab application, following the four steps above. Check it against this self-review list: scope and authorisation stated; methodology and coverage shown; every finding has impact, reproducible steps, severity with justification and a recommendation; chains of findings described; positive observations included; roadmap prioritised; sensitive data masked.
See a solution
A reference outline with plausible figures for a deliberately vulnerable lab:
1. Executive summary: 14 findings (2 critical, 4 high, 5 medium, 3 low); main chain: user enumeration
+ no lockout + no MFA = account takeover; start with access control and injection fixes
2. Scope and method: personal training lab, WSTG-based, grey box, two test accounts
3. Findings table: WEB-001 to WEB-014 with severity
4. Detailed findings: template applied to each
5. Positives: prepared statements on the profile form, secure cookie attributes on one cookie
6. Roadmap: immediately (WEB-001, WEB-002), short term (headers, CSRF tokens), planned (dependency inventory)
7. Appendices: tools, glossary, coverage table
Your numbers will differ. What matters is that your report can be read by an executive on one page and followed by a developer line by line, and that every claim is backed by something you actually did.
Key takeaways
- A professional audit consolidates notes into a coverage table, rated findings with chains, a prioritised roadmap and a clear report.
- Keep “not vulnerable” results: they prove coverage and become positive observations.
- Avoid tool-first thinking, skipped notes, scope mistakes and over-claiming.
- Web testing is one module of a full penetration test, which the next course covers end to end, with frameworks such as MITRE ATT&CK.
- Keep practising only in legal labs, read the OWASP references, and always work with written authorisation.
Well done for completing this course. Take the final assessment to validate your knowledge, then continue with “Ethical hacking: methodology of penetration testing”.