eWPT common mistakes
eWPT · Understand the traps and how to avoid them.
Starting exploitation or fuzzing before completing a structured manual walkthrough of the application: you log in, then immediately fire up a scanner or start injecting payloads into the first parameter you see, without mapping roles, endpoints, and parameters first.
Lab-style practice trains you to hunt for a single injected vulnerability, and time pressure makes scanning feel productive. On the exam the target is a real multi-function app, so unrecorded exploration means you lose track of which endpoints you already tested and miss whole feature areas.
What to do instead
Before any tooling, spend the first block of time doing a click-through as each available role while keeping a request log (proxy history plus a written endpoint table: URL, method, parameters, auth level, observed behaviour). Only start active testing once that table exists, and tick rows off as you test them.
Treating reconnaissance as a single tool run: you run one subdomain brute-force wordlist and one directory scan, get a handful of hits, and move on without correlating results across sources.
Recon output is noisy and partial; a single wordlist or one DNS source rarely surfaces the vhost, the staging subdomain, or the forgotten backup directory. Candidates also stop at 'found something' rather than pivoting on what was found.
What to do instead
Layer and cross-reference: passive sources (certificate transparency, DNS records, search engine dorks) plus active brute force with more than one wordlist, then resolve every host and probe each for virtual-host behaviour. Feed every discovered hostname and path back in as a new seed (new vhost, new directory, new parameter) and record the source of each finding.
Reporting a scanner finding as a vulnerability without manual confirmation, e.g. submitting 'SQL injection' because a tool flagged a parameter, with no proof of injection and no demonstrated impact.
Automated tools produce false positives and generic descriptions, and candidates under time pressure copy the tool output rather than reproducing the issue by hand. This also leads to reporting issues on pages that are static or unreachable.
What to do instead
Reproduce every candidate by hand with a minimal, controlled request, and keep the raw request/response pair as evidence. If you cannot show a differential response, an error, or a data leak caused by your payload, downgrade it to an observation or drop it. Report only what you can demonstrate.
Testing access control only with the highest-privilege account: you confirm that an admin can reach admin functions and never replay the same request with a lower-privilege session or no session at all.
Privilege-escalation and IDOR bugs are invisible unless you compare responses across identities. Candidates get absorbed in functionality testing with the account they were given and forget that authorisation must be tested by substitution, not by observation.
What to do instead
For every state-changing or data-returning endpoint, capture the request in one role and replay it with (a) a lower-privileged user's cookie, (b) no cookie, and (c) a manipulated identifier or role parameter. Record the status code, body length, and whether the action actually took effect server-side, not just whether the UI hid the button.
Skipping the client-side and configuration layer because 'the interesting bugs are server-side': you never inspect cookies for missing flags, security headers, TLS setup, HTTP methods, CORS policy, or directory listing.
These checks feel low-value compared with injection, and candidates assume the exam only rewards deep exploitation. In practice they are quick, deterministic findings that are easy to evidence and easy to miss when attention is fixed on payload crafting.
What to do instead
Keep a short configuration checklist and run it once per host early: cookie attributes (Secure, HttpOnly, SameSite), presence of HSTS/CSP/X-Frame-Options, allowed HTTP verbs via OPTIONS, CORS with an attacker Origin, TLS certificate and protocol version, exposed dotfiles and directory listing. Each item takes one request and yields a reportable line.
Losing the exploitation chain: you find several low-severity issues and report them as a flat list, never attempting to combine them (e.g. information disclosure leading to credentials, then to an authenticated area, then to injection) or to escalate to demonstrable impact.
Candidates treat findings as independent checklist items and stop at first proof, partly because chaining takes extra time and partly because they do not think in terms of attacker goals. This caps the severity of the report and hides the real risk.
What to do instead
After each confirmed finding, ask 'what does this give me next?' and follow it: credentials to a login, a token to an API, a file read to source code, source code to a hidden endpoint. Document the chain as an ordered sequence of requests so the report shows the path from unauthenticated entry to final impact.
Testing only the parameters visible in the browser: you ignore hidden form fields, JSON body keys, custom headers, path segments, and parameters accepted by the API but not rendered in the UI.
The visible UI is a filtered view of the request surface; frameworks accept extra fields and the server often trusts them. Candidates anchor on what the page shows and never diff the request against the rendered form.
What to do instead
For each request, enumerate the full input surface: query string, body (form or JSON, including nested keys), headers (including X-Forwarded-For, Referer, User-Agent), cookies, and path fragments. Add parameters the app does not display and watch for behaviour changes; compare the rendered form fields against the submitted body to spot hidden or client-side-only fields.
Writing the report as a narrative of what you did rather than a reproducible finding: no exact request, no affected URL, no clear impact statement, and remediation phrased as 'sanitise input'.
Candidates write reports at the end from memory, focus on process ('I used tool X'), and reuse generic advice. A reader cannot reproduce the issue, so the finding looks unverified and the remediation looks boilerplate.
What to do instead
Use a fixed template per finding: title, affected endpoint and parameter, prerequisites/role, step-by-step reproduction with the raw HTTP request and response, observed vs expected behaviour, concrete impact (what data or action an attacker gains), severity with justification, and remediation specific to the technology in use (e.g. parameterised queries, server-side authorisation check, output encoding context).
Mishandling session and authentication testing: you test login brute force without checking lockout, never inspect token generation for predictability, never test logout or password-reset flows, and never check whether a session survives a privilege change.
Authentication is treated as a gate to get through rather than a target. Candidates assume the login works correctly and spend their time on the application behind it, missing flawed reset tokens, session fixation, and missing server-side logout.
What to do instead
Treat auth as a test area of its own: inspect token entropy and length, check whether the session ID rotates on login and on privilege change, verify server-side invalidation on logout, exercise the password-reset flow end to end (token predictability, reuse, expiry, host-header influence), and test lockout/rate limiting with a small number of requests.
Poor time and coverage management: you sink the whole session into one stubborn parameter, or spread so thin that no finding is fully proven, and you submit with untested areas and unverified notes.
Deep-diving one target feels like progress and avoids the discomfort of moving on; conversely, chasing every lead prevents depth. Without a plan, the highest-value areas (authentication, access control, injection in data-handling endpoints) get whatever time is left.
What to do instead
Budget the session in blocks: recon and mapping, then authentication and access control, then injection and business logic, then reporting, with a hard stop for each. Keep a running findings log with a status per item (candidate, confirmed, written up) and prune candidates that resist ten minutes of testing. Reserve the final block for writing up confirmed findings only.