eWPTXv3: The Complete Study Blueprint for INE's Toughest Web App Pentesting Exam

A domain-by-domain breakdown of what to study, how to think about each vulnerability class, and where to practice legally — before you sit the hardest practical web app exam INE has ever shipped.

If you've looked at INE Security's certification ladder, you already know the shape of it: eJPT → eCPPT → eWPT → eWPTXv3. The "X" stands for eXtreme, and it earns that name. This isn't a multiple-choice exam with a few guided labs bolted on. It's 18 hours, 45 questions, real targets, 100% hands-on, auto-graded. There's no partial credit for knowing the theory — you either popped the target or you didn't.

I spent a chunk of the last few weeks building a structured study companion for candidates preparing for this exam, organizing INE's official domains into something you can actually plan a study schedule around. This post is the long-form version of that guide — every domain, every key concept, every testing approach, laid out the way I wish someone had laid it out for me before I started.

One thing up front: this is not a reproduction of INE's proprietary exam or Skill Check lab content, and it's not a copy-paste exploitation toolkit. Everything here is conceptual — what a vulnerability class is, how a tester approaches confirming it, and how it gets fixed. The hands-on reps are meant to happen inside INE's own labs, PortSwigger's Web Security Academy, or deliberately vulnerable practice apps — where it's safe and legal to actually pull the trigger.

eWPTXv3 at a Glance

INE Security describes eWPTXv3 as its most advanced web application penetration testing certification — built for professionals who already have intermediate-to-advanced experience, not a starting point.

Difficulty: Advanced / Expert Time limit: 18 hours Questions: 45 Validity: 3 years (renewable through INE's renewal program)

Logistics worth knowing before you book: The exam voucher is valid 180 days from purchase, and includes one free retake within 14 days of your first attempt. You need an active INE Premium subscription to purchase the voucher. Grading is automatic, with a per-domain performance breakdown delivered within hours — so you'll know exactly where you lost points.

Who it's actually for: experienced web app pentesters, red team operators, bug bounty hunters, cybersecurity consultants, security engineers/analysts, and software/DevSecOps engineers who want to formalize offensive AppSec skills.

Recommended prep path: INE's Advanced Web Application Penetration Testing learning path (included in Premium), and — somewhat unusually — INE explicitly recommends finishing the Threat Hunting Professional path first. A solid eWPT foundation is assumed; this exam is explicitly built as the tier above it, not a replacement for it.

The Domain Weight Map

Seven domains make up the exam, and they are not weighted evenly. This matters a lot for how you allocate study time:

Methodology — 10% Reconnaissance — 15% Auth Attacks — 15% Injection — 15% API Testing — 25% Server-Side — 10% WAF Bypass — 10%

Notice anything? API Penetration Testing alone is worth a quarter of the exam — more than any other single domain, and roughly equal to Methodology and WAF Bypass combined. If you're going to over-invest your prep time anywhere, this is where. Let's go domain by domain.

Domain 1 — Web Application Penetration Testing Methodology (10%)

Official objectives: assess a web application against methodological, industry-standard best practices; identify and prioritize testing objectives based on business impact and risk.

This domain isn't really about a single technical skill — it's about whether you approach an engagement like a professional or like someone running tools at random. A structured methodology (PTES- or OWASP WSTG-style) is what separates the two.

Key concepts: Scoping and rules of engagement get agreed before the first request is ever sent. Risk-based prioritization matters: a reflected XSS on a marketing page and an IDOR on a billing endpoint are not equally urgent, even if both are technically "valid findings." Documentation discipline starts on day one — not after you find something interesting.

Testing approach: build a written test plan before you touch the target. Map business logic and data flows, not just the technical attack surface. Keep your methodology consistent across engagements so your findings are reproducible and defensible in front of a client.

Why it matters defensively: organizations should be requesting a documented methodology from any tester or vendor they hire, and triaging findings by business impact — not just raw technical severity.

Domain 2 — Web Application Reconnaissance (15%)

Official objectives: passive and active recon using WHOIS, DNS enumeration, and network scanning; extracting domain/subdomain/IP-range intel; fuzzing for input-validation issues; Git-specific tooling to find secrets in exposed code.

Recon quality determines everything downstream. In my experience — and this shows up constantly in real engagements, not just exam scenarios — a forgotten staging subdomain or an exposed .git directory is frequently where the real vulnerabilities live. Spend real time here before you even think about exploitation.

Key concepts: Passive recon first: WHOIS, certificate-transparency logs, DNS history, search-engine dorking — nothing that touches the target directly. Active recon follows: subdomain brute-forcing, port/service scanning, technology fingerprinting. Content discovery via fuzzing surfaces hidden directories, parameters, and virtual hosts the visible UI never shows you. Exposed .git directories and leftover CI/CD configs are a recurring, high-value source of leaked secrets.

Defensive mitigations: decommission or properly restrict staging/legacy subdomains; scan your own repos for committed secrets before they're pushed; rate-limit and monitor for automated enumeration patterns.

Domain 3 — Authentication Attacks (15%)

Official objectives: test Basic, Digest, and OAuth authentication via credential stuffing and brute force; identify SSO vulnerabilities; exploit session-management flaws (fixation, hijacking); exploit OAuth/OpenID Connect weaknesses.

Key concepts: Credential stuffing (reusing breached credential pairs) vs. brute force (guessing) call for genuinely different detection and defense strategies — don't treat them as the same attack. SSO trust relationships tend to break down specifically at the handoff between identity provider and service provider. Session tokens matter on three axes: entropy, transport security, and invalidation on logout. OAuth/OIDC weak points to probe: redirect_uri validation gaps, a missing or ignored state parameter, implicit-flow token leakage, over-broad scope grants.

Testing approach: map the entire authentication flow end-to-end — every redirect, every intermediary. Test each state transition (login, logout, password reset, token refresh), not just the login form. Never trust a client-reported authentication flag; enforcement has to be verified server-side.

Canonical example:
' OR '1'='1' --   // classic auth-bypass probe string — starting point, not an endpoint

Canonical example:
' OR '1'='1' --   // classic auth-bypass probe string — starting point, not an endpoint

Defensive mitigations: rate-limit and lock out in a way tuned against both brute force and self-inflicted denial of service; strict redirect_uri allowlisting with mandatory state validation; short-lived tokens with proper server-side invalidation on logout.

Domain 4 — Injection Vulnerabilities (15%)

Official objectives: identify and exploit SQL injection (error-based, blind, time-based); use SQLMap and similar tooling effectively; identify and exploit NoSQL injection; extract data from compromised databases.

Key concepts: Error-based vs. blind (boolean/time-based) vs. out-of-band SQLi each require progressively more inference as the application gives you less direct feedback. NoSQL injection manipulates query structure (operators, objects) rather than string syntax — your testing mindset has to shift accordingly. Using SQLMap well means understanding what it's doing under the hood — not just pointing it at a URL and waiting.

Testing approach: establish a baseline response, then test for differential behavior against true/false conditions. Escalate from confirmation to extraction only within your authorized scope and rules of engagement.

Canonical example:
' AND '1'='1 vs. ' AND '1'='2   // the baseline differential every blind-SQLi test starts from

Canonical example:
' AND '1'='1 vs. ' AND '1'='2   // the baseline differential every blind-SQLi test starts from

Defensive mitigations: parameterized queries / prepared statements — the only real fix for SQLi; least-privilege database accounts (no FILE or xp_cmdshell for a web-app user); strict server-side schema validation for NoSQL query inputs.

Domain 5 — API Penetration Testing (25% — the big one)

Official objectives: hands-on pentesting of API endpoints; automation tooling for efficient API testing; parameter-manipulation analysis; rate-limiting weakness testing and bypass in a controlled environment.

This is the single largest domain on the exam, and for good reason: APIs skip the UI's implicit guardrails entirely. The real attack surface here only shows up through documentation or captured traffic — not through clicking around.

Key concepts: BOLA/IDOR is the most common real-world API bug: a user is authenticated, but not authorized for this specific object. This single bug class alone has caused more real-world breaches than almost any other API flaw. GraphQL introspection, if left enabled, hands a tester a complete map of the entire data graph — including fields never exposed anywhere in the UI. JWT issues: algorithm confusion (RS256/HS256 mix-ups), weak signing secrets, improper signature validation. Mass assignment: client-supplied JSON fields get bound directly to internal object fields the client was never meant to touch. Rate-limiting is itself testable — header spoofing, distributed sources, and parallel race conditions can all defeat naive limits.

Testing approach: enumerate every endpoint and method from documentation and intercepted traffic — not just what the UI calls. Swap object IDs between two low-privilege test accounts to probe authorization directly. Inspect every JWT's header and claims. Fuzz request bodies for fields the backend silently accepts.

Defensive mitigations: enforce object-level authorization server-side on every single call; disable GraphQL introspection in production (or gate it behind auth); pin and explicitly reject unexpected JWT signing algorithms; allowlist bindable fields instead of trusting the full request body; rate-limit by authenticated identity, not only source IP.

Domain 6 — Server-Side Attacks (10%)

Official objectives: identify and exploit SSRF against server-side services; perform deserialization attacks (up to arbitrary code execution or privilege escalation); perform LDAP injection to bypass auth or extract data.

Key concepts: SSRF turns the server itself into the attacker's proxy — especially dangerous in cloud environments, where internal metadata services often expose temporary credentials. Insecure deserialization is dangerous precisely because untrusted data gets reconstructed into live objects; if "gadget" classes exist on the classpath, that reconstruction alone can trigger code execution. LDAP injection manipulates directory query filters in a way conceptually similar to SQLi, but aimed at authentication/directory backends. Closely related: XXE — an XML parser that resolves external entities can be abused similarly to SSRF or for local file disclosure.

Testing approach: find every feature that accepts a URL, file path, or serialized blob from the user. Treat any confirmed access to cloud instance metadata as a critical finding — never "just informational." Identify deserialization entry points via format fingerprinting (base64 blobs, language-specific serialization markers).

Defensive mitigations: allowlist outbound destinations instead of blocklisting; enforce IMDSv2 with a hop limit of 1 on cloud instances; never deserialize untrusted data directly (prefer schema-validated formats like JSON); disable external entity resolution and DTD processing in every XML parser, by default.

Domain 7 — Filter Evasion & WAF Bypass (10%)

Official objectives: analyze and test WAF rules for weak configurations; hands-on WAF evasion via encoding, obfuscation, and payload fragmentation; bypass input validation via obfuscation, encoding, and content-type manipulation — with emphasis on SSRF and XXE.

Key concepts: WAFs are pattern matchers, not true parsers — anything that changes a payload's surface form while preserving its effect on the backend can defeat a naive signature. Alternate encodings: URL encoding, double URL encoding, Unicode normalization tricks, HTML entity encoding. Case manipulation and inline comment injection can break regex-based signatures that assume a fixed keyword form. Payload fragmentation across parameters or requests, and content-type confusion (e.g. sending JSON to an endpoint expecting XML), can reach a differently-configured parser entirely.

Testing approach: identify exactly what triggers a block — character, keyword, or pattern — through controlled, incremental probing. Then test whether the same semantic payload survives when encoded differently. Notably, this domain explicitly pairs with SSRF and XXE on the exam — evasion technique and target vulnerability are tested together, not in isolation.

Canonical example:
SELECT vs. SeLeCt vs. SEL/**/ECT   // same semantics, different signature footprint

Canonical example:
SELECT vs. SeLeCt vs. SEL/**/ECT   // same semantics, different signature footprint

Defensive mitigations: defense belongs at the parser/application layer, not only at the WAF edge; canonicalize and normalize input before validation, not after; treat the WAF as one layer of defense-in-depth — never the sole control.

The Skill-Check Methodology Framework

Beyond the seven domains, there's a process layer worth internalizing before you sit any skill-check-style lab — exam or otherwise. This is a general framework reflecting how experienced testers actually structure their work (not a reproduction of INE's proprietary lab content — practice the specifics inside your own labs):

1. Reconnaissance & Scoping — confirm authorized scope, then map the application: endpoints, parameters, technologies, via passive and active recon.
2. Enumeration & Mapping — catalog every input, authentication state, and role boundary. Build a mental (or written) map before testing a single payload.
3. Vulnerability Hypothesis — for each input, reason about what vulnerability classes are plausible given how it's handled. Don't test randomly.
4. Controlled Validation — test the least-impactful proof possible to confirm a hypothesis before escalating toward real impact.
5. Impact Assessment — once confirmed, assess realistic business impact rather than stopping at "it's vulnerable."
6. Documentation — evidence (requests/responses), clear reproduction steps, and defensible severity reasoning, written as you go, not after.
7. Remediation Review — the step most guides skip: map each finding to a concrete fix, and re-test it.

Burp Suite workflow, mapped to that process: Proxy — intercept and map traffic as you browse the target Repeater — manually iterate on a single request to test one hypothesis at a time Intruder — automate payload-position fuzzing for discovery and encoding tests Collaborator / OOB — confirm blind and out-of-band findings via external interaction

Core Toolkit & Where to Practice Legally

Toolkit: Burp Suite — intercepting proxy & the core manual-testing workbench OWASP ZAP — open-source alternative proxy/scanner ffuf / gobuster — content, subdomain, and parameter discovery via fuzzing SQLMap — automates SQL injection confirmation & extraction jwt_tool — inspect and test JWT structure & signature handling Postman / Insomnia — API exploration, collection-based endpoint testing Nuclei — template-based vulnerability scanning at scale subfinder / amass — passive & active subdomain enumeration

Where to actually practice — legally: INE Labs — your Premium subscription's own authorized, built-for-this lab environment PortSwigger Web Security Academy — free, public, legal hands-on labs for almost every technique above OWASP Juice Shop / DVWA / WebGoat — deliberately vulnerable practice applications designed specifically for safe, legal reps

One closing principle I'd underline: pair every tool in that list with a methodology step. Tools without process just make noise faster — they don't make you a better tester.

Final Word

eWPTXv3 doesn't reward memorized payloads. It rewards testers who can walk into an unfamiliar application, build a mental model of it fast, reason correctly about what's plausible given how each input is handled, and document the finding well enough that someone else could reproduce it from your notes alone. That's the actual skill the exam is measuring — the domain percentages just tell you where INE thinks that skill gets exercised the most (and clearly, that's APIs).

If this breakdown is useful, I also put together a full PDF study companion(check my linkedin) with this content organized domain-by-domain for easier reference while planning your study schedule. Happy to share it — just reach out.

Good luck to everyone grinding toward eWPTXv3. See you on the other side of 18 hours.

Davud Qasimov — Community Content Contributor @ INE linkedin.com/in/davud-qasimov github.com/DavudQasimov medium.com/@qasimovdavud39