Skip to content
Hez's Docs

PWPA Takeaways as Software Engineer

I recently passed PWPA (Practical Web Pentest Associate) from TCM Security, shortly after eJPT. Where eJPT is broad — networking, host enumeration, a bit of everything — PWPA is narrow and deep: it’s entirely focused on manually testing web applications and APIs. That narrower scope is what made it more directly useful to me as a backend engineer. This is a writeup of what changed in how I think about the APIs and web apps I build.

PWPA is hands-on and manual by design. It leans heavily on Burp Suite and expects you to actually walk through an application’s logic, not just run a scanner against it. That manual-first approach is the biggest difference from eJPT, and it’s also the part that transferred most directly to engineering judgment.

1. Manual testing taught me to read requests, not just endpoints

Section titled “1. Manual testing taught me to read requests, not just endpoints”

A scanner checks for known patterns. PWPA pushes you to intercept every request, read every parameter, and ask what the server is actually trusting. That habit — opening Burp and watching what a “simple” form submission actually sends — exposed a lot of implicit trust that’s invisible when you only read the API spec.

As an engineer, this reframed how I review my own endpoints:

  • What does the client control that the server shouldn’t trust blindly — IDs, roles, prices, quantities, feature flags passed as parameters?
  • What’s enforced only in the frontend (a disabled button, a hidden field, a client-side check) and silently unenforced on the server?
  • What does a request look like with every “optional” assumption stripped away?

A lot of the vulnerabilities PWPA covers come from exactly this gap: the client was trusted to behave, and the server never checked.

2. Authorization testing was the single most transferable skill

Section titled “2. Authorization testing was the single most transferable skill”

PWPA spends a lot of time on broken access control — horizontal privilege escalation (accessing another user’s data) and vertical privilege escalation (accessing another role’s functionality). This is the same object-level and function-level authorization problem that shows up constantly in backend API design.

What changed for me specifically:

  • I now treat every endpoint that accepts an ID as a potential IDOR until I’ve verified ownership checks myself, not just trusted that “the ORM handles it.”
  • I think about authorization per action, not per session. Being logged in answers “who is this,” not “are they allowed to do this specific thing.”
  • Multi-tenant systems get extra scrutiny — a missing WHERE tenant_id = ? clause is functionally the same bug as the access-control failures PWPA has you exploit.

This is the part of the certification that mapped most directly onto my day job, more than any other module.

3. API-specific testing closed gaps that web-only training misses

Section titled “3. API-specific testing closed gaps that web-only training misses”

PWPA doesn’t stop at traditional web apps — it covers API testing specifically, including REST APIs and common issues like excessive data exposure, mass assignment, and improper rate limiting. That’s a more direct match to backend work than a lot of general pentesting material, which still assumes a browser-rendered app.

Concretely, this changed how I think about API responses and input binding:

  • Mass assignment made me reconsider every endpoint that binds a request body directly to a model or struct — an API that accepts a JSON object and updates a record should never let the client set fields like role or isAdmin just because they happened to include them in the payload.
  • Excessive data exposure made me look harder at API responses that return a whole internal object “because it’s convenient,” rather than explicitly selecting the fields a client should actually see.
  • Rate limiting and abuse cases stopped being a nice-to-have and became something I ask about during API design, not after an incident.

4. Business logic flaws don’t show up in automated scans

Section titled “4. Business logic flaws don’t show up in automated scans”

A theme throughout PWPA is that the most interesting bugs are often not technical vulnerabilities at all — they’re legitimate functionality used in a sequence the application didn’t anticipate. Skipping a step in a checkout flow, replaying a request out of order, or abusing a discount code’s edge cases are all “valid” requests that break application logic.

This is probably the hardest lesson to operationalize, but the most valuable one: no amount of input sanitization catches a business logic flaw, because nothing about the request is technically malformed. The only real defense is designing workflows that enforce state transitions server-side, and not assuming the client will follow the UI’s intended path.

5. Burp Suite became a permanent part of my own debugging toolkit

Section titled “5. Burp Suite became a permanent part of my own debugging toolkit”

This one is more practical than philosophical: after using Burp Suite extensively through PWPA, it’s now part of how I debug my own APIs during development — intercepting and replaying requests, tampering with parameters, and checking what my own backend actually accepts versus what I assumed it accepts. It’s a faster feedback loop than writing a one-off test script for “what happens if this field is missing or malformed.”

How PWPA compares to eJPT, for engineers deciding between them

Section titled “How PWPA compares to eJPT, for engineers deciding between them”

If you’re a backend or API-focused engineer and can only do one, PWPA is the more directly applicable certification — it’s narrowly focused on exactly the kind of application you build and ship. eJPT is more useful if you also want exposure to networking, host enumeration, and the broader “how does an attacker get into a network” picture, which is less specific to application code but still useful context.

Doing both, in sequence, worked well for me: eJPT built the general methodology and comfort with tooling, and PWPA went deep on the web and API-layer skills that apply most directly to my actual job.

Learning resources

Section titled “Learning resources”

Final thought

Section titled “Final thought”

eJPT changed how I think about systems in general. PWPA changed how I think about the specific thing I build most often: APIs. Manually poking at requests, chasing authorization boundaries, and thinking through business logic as an attacker would has made me noticeably more skeptical of my own “obviously fine” endpoints — which is exactly the instinct I was hoping to build.