eWPTX common mistakes
eWPTX · Understand the traps and how to avoid them.
Reporting a reflected XSS after only confirming that the payload appears unencoded in the response body, without proving it executes in a browser context or identifying the correct sink (HTML body vs attribute vs script block).
Tool output and simple string-matching make reflection look like execution, and candidates skip manual context analysis because the payload 'obviously' came back.
What to do instead
For each injection point, classify the exact output context, then choose a context-appropriate payload and verify execution with a controlled browser or headless check; if execution cannot be shown, downgrade the finding to an encoding/reflection observation and state the limitation.
Treating a single decoded payload as sufficient while ignoring that the application applies multiple decoding layers or a WAF normalisation pass, so the reported bypass does not fire in the real request path.
Candidates test the payload in isolation (e.g. in a local decoder) rather than through the full request chain, and stop at the first layer that decodes.
What to do instead
Reproduce the payload end-to-end through the actual proxy request, confirm the server-side sink receives the intended value, and document each encoding/normalisation layer the payload survives.
Claiming SQL injection from a boolean or time-based signal without establishing a stable baseline, so natural response-time or content variance is misread as injection.
Time-based and boolean tests are noisy; candidates run one comparison instead of repeated controls and misattribute jitter or caching to the payload.
What to do instead
Run multiple control requests and multiple payload requests, compare distributions rather than single samples, and confirm with an independent technique (e.g. error-based or a second boolean pair) before asserting injection.
Reporting an access-control flaw based only on a 200 status or a different response length, without confirming that the response actually contains another user's data or a privileged action result.
Status codes and body sizes change for many benign reasons (redirects, empty states, templating), and candidates equate 'different' with 'authorised bypass'.
What to do instead
Compare concrete response content (specific fields, identifiers, rendered values) between a low-privilege and high-privilege session, and demonstrate a real data or action difference with both requests captured.
Submitting a finding list built from scanner output with severities copied from the tool, including unverified items such as 'possible SSRF' or 'outdated component' with no exploitation attempt.
Time pressure and the volume of scanner noise tempt candidates to pad the report, and severity labels from tools look authoritative.
What to do instead
Manually triage every scanner item, keep only findings you personally reproduced, set severity from demonstrated impact (data reached, privilege gained, actions possible), and move unverified items to an appendix labelled as unconfirmed.
Chasing a deep exploit chain on one hard target while never enumerating the wider attack surface (subdomains, alternate ports, API versions, staging hosts), leaving large areas untested when time expires.
A single interesting vulnerability creates tunnel vision, and candidates underestimate how much of the score comes from breadth of coverage.
What to do instead
Timebox each target: complete a structured enumeration pass across hosts, ports, endpoints and parameters before deep-diving, and keep a coverage checklist so no area is left untouched.
Writing the final report as a raw list of payloads and screenshots without impact statements, reproduction steps, or remediation, so findings cannot be independently verified by a reader.
Candidates treat the report as an afterthought and assume the grader shares their mental context from the testing session.
What to do instead
Use a fixed template per finding: title, affected asset, preconditions, numbered reproduction steps with exact requests, observed result, business impact, and remediation; write it as you go rather than at the end.
Failing to preserve evidence at the moment of exploitation (raw request/response, timestamps, session identifiers), then reconstructing it later from memory or re-running against a changed target.
Momentum during exploitation discourages stopping to capture, and candidates assume the state will still be reproducible afterwards.
What to do instead
Capture the full request and response pair for every confirmed step into an evidence folder as it happens, and note the exact session, account and time used so the chain can be replayed.
Testing destructive or state-changing actions (account deletion, mass data modification, password resets on live accounts) during a simulation without confirming scope or using a controlled test account.
Candidates focus on proving impact and forget that the engagement boundary and safe-testing rules still apply in a simulated environment.
What to do instead
Before any state-changing test, confirm it is within scope, use dedicated test accounts and data, prefer the least destructive proof (e.g. a single reversible change) and record what was altered.
Misjudging time allocation: spending most of the window on initial reconnaissance and tool setup, leaving no time to verify findings, chain them, or write the report.
Reconnaissance feels productive and open-ended, and candidates do not reserve fixed blocks for verification and reporting.
What to do instead
Set an explicit schedule up front with hard cutoffs for recon, exploitation, verification and reporting, and enforce a rule that no new target is started once the reporting block begins.