Most advanced certifications ask you to find vulnerabilities and document them. The HTB Certified Web Exploitation Expert asks for something harder: find the vulnerability, write a working exploit for it, and then write the patch that fixes it.
That combination is what separates CWEE from CWES and from most web certifications on the market. It is also why preparation material that only shows walkthroughs leaves you unprepared for the part that decides the result.
What the exam actually requires
- Eligibility: the Senior Web Penetration Tester job-role path completed 100%. Every module ends with a skills assessment.
- Format: black-box and white-box testing against multiple heterogeneous applications, over VPN or Pwnbox.
- Lab access: ten days on a dedicated instance you can reset.
- Deliverables: flags submitted on the exam page, plus a commercial-grade report uploaded within ten days of starting.
- Report content: how you identified each vulnerability, how you exploited it, the exploit code itself, and a patch or remediation for the code you reviewed.
- Attempts: two. Vouchers expire after one year; the retake must start within fourteen days of feedback.
- Validity: no expiry.
Read the report requirement again, because it is where most candidates lose the certification. Finding the bug is table stakes. Explaining the root cause in code, demonstrating a functional exploit, and proposing a patch that would actually prevent it is the actual assessment.
Black box and white box are different exams
The exam includes both, and candidates tend to be strong in one and weak in the other.
Black box rewards the skills you already practise: mapping an application, reading behaviour, testing authentication and access control, chaining findings. If you have done CWES or serious bug bounty work, this part is familiar.
White box is where preparation usually falls short. You get source code and must find the flaw by reading it. That requires a different habit: tracing data flow from input to sink, understanding framework conventions, and recognising the patterns where developers consistently make mistakes.
A practical way to train it: take an open-source application you use, pick one endpoint, and trace every parameter from the route handler to the database call. Write down each place where validation could fail. Do this weekly. Reading code with a purpose is a skill, and it decays without practice.
The three deliverables, in order of difficulty
| Deliverable | What it proves | Common failure |
|---|---|---|
| Flags | You reached the objective | Chasing hosts instead of objectives |
| Working exploit | You understand the flaw mechanically | Payload works once, breaks on a second run |
| Patch | You can fix what you found | Blocking the specific payload, not the class of bug |
The exploit and the patch are connected. If your patch only blocks the string you sent, it is not a patch — it is a signature. Reviewers look for the fix at the level of the root cause: parameterised queries instead of escaping, allowlists instead of blocklists, type checks instead of string comparison.
How to use the ten days
The lab and the report share one deadline. Plan backwards from the upload, not forwards from the start.
| Days | Focus |
|---|---|
| 1 | Read the letter of engagement, inventory applications, set up notes and evidence folders |
| 2–4 | Black-box testing, first flags, first findings written up |
| 4–6 | White-box review, source analysis, exploit development |
| 7–8 | Remaining objectives, patch development, regression check |
| 9 | Full report draft |
| 10 | Evidence review, patch verification, upload |
Two habits keep this realistic:
- Write the finding when you find it. Evidence collected live includes the request, the response, and the reasoning. Reconstructed later, it loses the detail that makes it credible.
- Keep exploits small. A ten-line Python script that reliably reproduces the issue beats a fragile chain of manual requests. The exploit has to run when the reviewer runs it, not just when you did.
What the report has to show
The template is provided. Quality is what varies:
- Root cause in code — the specific line or pattern that creates the flaw, not a description of the symptom.
- Exploit with reproduction steps — dependencies, invocation, expected output.
- Impact — what an attacker gains, in business terms as well as technical.
- Patch — the code change, with a short explanation of why it closes the class of bug.
- Verification — proof that the patch blocks the original exploit and does not break normal functionality.
That last item is often skipped and it is the difference between a patch and a suggestion. Apply your fix, re-run your exploit, show the failure. Two screenshots, thirty seconds of work, a materially stronger report.
Preparation that maps to the exam
The Senior Web Penetration Tester path is the syllabus: advanced injections, authentication mechanisms, HTTP-level attacks, deserialization, white-box review, parameter logic bugs. Complete the skills assessments properly rather than skimming to unlock the voucher.
Three exercises that transfer directly:
- Exploit development in Python. Write your own client for a vulnerable app instead of using a browser and a proxy. Handling sessions, encoding, and retries in code exposes assumptions you did not know you had.
- Patch and re-test. Take a lab you solved and fix the vulnerability in the source. Then run your exploit again. If it still works, your patch was incomplete.
- Code review under time pressure. Give yourself ninety minutes to find one vulnerability in an unfamiliar codebase. Write the finding and the fix in that window.
CWEE or CWES first?
HTB recommends CWES or equivalent knowledge before CWEE, and the recommendation is practical rather than administrative. CWEE assumes you can already exploit web vulnerabilities fluently; it adds source review, custom exploit development, and patching on top. Candidates who skip the foundation spend the exam learning two things at once.
If you can complete medium web labs without hints, read a route handler and identify the injection point, and write a small exploit script without a framework, you are ready to prepare for CWEE. If two of those are shaky, CWES is the better next step.
Common failures
- Reporting the symptom, not the cause. “Input is not sanitised” is not a root cause. The missing parameterised query is.
- Exploits that only work manually. If the reviewer cannot run it, it does not count as developed.
- Patches that block a payload. Blacklist fixes fail the intent of the requirement.
- Starting the report on day nine. The report is half the certification and takes longer than candidates expect.
- Ignoring the letter of engagement. Objectives are graded; out-of-scope work is wasted work.
Where to go next
For the certification overview, pricing, and available study material, see the CWEE certification hub. If you are deciding between the two web certifications, the CWES hub covers the specialist level, and the report template guide covers the document structure that carries across HTB exams.
Certification names belong to Hack The Box. This is independent study material, not official course content.
Web application security specialist and bug bounty hunter. OSWA and OSWE certified, focused on web exploitation, API security and source-code review. Writes our web exploitation walkthroughs and reviews report structure for web-focused certifications.