Web Pentest

---
name: web-pentest
description: >-
  Guides authorized web-application penetration testing from recon through
  reporting. Use this skill whenever the user is testing a website or web app
  for security issues — assessing their own site or staging environment, a
  client engagement with a signed scope, a bug-bounty target in scope, a CTF,
  or a practice lab (PortSwigger Academy, OWASP Juice Shop, DVWA, HackTheBox).
  Trigger it for requests like "pentest this site", "find vulns in my web app",
  "help me test for SQLi/XSS/IDOR/SSRF", "walk me through testing auth on this
  endpoint", "map the attack surface", "write up this finding", "validate this
  RCE / get a reverse shell", or "which Burp / ffuf / nuclei command should I
  run here" — even when the user doesn't say the word "pentest". Follows the
  OWASP Web Security Testing Guide, covers unauthenticated and authenticated
  (incl. multi-tenant) testing, organizes tooling into a repeatable workflow,
  and produces clean findings reports. The target's third-party platform / host
  / marketplace is out of scope by default.
---

# Web Application Penetration Testing

This skill helps you run a disciplined, methodology-driven web-app security test
and turn what you find into a clear report. It is built around the OWASP Web
Security Testing Guide (WSTG) so coverage stays systematic instead of ad-hoc.

## Authorization comes first — every time

Web pentesting is only legal and ethical against targets you are allowed to
test. Before any **active** testing (sending payloads, fuzzing, brute-forcing,
exploiting), confirm the target falls into one of these:

- The user's **own** application or infrastructure.
- A **client engagement** with a signed scope / rules of engagement (RoE).
- A **bug-bounty** program where the target is explicitly in scope.
- A **CTF** or a **practice lab** the user controls or is licensed to use
  (e.g. PortSwigger Web Security Academy, OWASP Juice Shop, DVWA, HackTheBox,
  TryHackMe, a local Docker target).

If the target or authorization is unclear, ask one direct question before
proceeding: *"Is this a target you're authorized to test, and what's the
scope?"* Passive reading of public docs is fine; active testing of a
third-party site without authorization is not — don't help with it, and say
why. This keeps the engagement legal and keeps the user out of trouble.

Record the agreed scope at the start so it anchors everything else:

- In-scope hosts / domains / IP ranges, and anything explicitly **out** of scope.
- Allowed test windows and any rate limits (don't DoS a target you're paid to
  protect).
- Whether destructive tests, account creation, or data modification are permitted.
- A point of contact for "stop" and for emergencies.
- **Third-party and platform infrastructure is out of scope by default.** Test
  the target's own code, configuration, and data — not the SaaS platform, host,
  CDN, payment provider, identity provider, or marketplace it runs on or is
  embedded in (e.g. the hosting platform or app marketplace itself). Those
  belong to other owners; report issues there to that vendor instead of testing
  them. Confirm with the client before touching anything shared.

## The workflow

Testing proceeds in phases. Each phase feeds the next; don't skip recon to jump
to exploitation, because you can't test an attack surface you haven't mapped.

1. **Scope & RoE** — confirm authorization, record scope (above).
2. **Recon & mapping** — enumerate the attack surface: subdomains, hosts,
   endpoints, parameters, technologies, auth mechanisms, roles.
3. **Vulnerability testing** — work the OWASP WSTG categories against the mapped
   surface. This is the bulk of the work.
4. **Exploitation & impact** — for confirmed issues, demonstrate real impact
   safely (enough to prove it, not enough to cause harm).
5. **Reporting** — write each finding up with evidence, severity, and a fix.

Use the phase list as a checklist. As you go, keep running notes of every host,
endpoint, parameter, and observation — the report is only as good as the notes.

## Authenticated testing

The highest-value categories — access control, injection in protected routes,
and business logic — live **behind login**, so an unauthenticated pass can only
cover part of the surface. To reach the rest, get credentials up front:

- **Test accounts at each role** — ideally two accounts at the same privilege
  level (to prove horizontal IDOR) plus one of each higher role (to prove
  vertical escalation). Ask the client to provision these.
- **How the session is obtained** — form login, OAuth/SSO, API key, or a signed
  session token (JWT). Capture a valid session in your proxy and learn how it's
  carried (cookie vs `Authorization` header) so you can replay and tamper.
- **Multi-tenant apps** — if the app serves multiple organizations/tenants, get
  accounts in **two different tenants**; cross-tenant data access is usually the
  single highest-impact bug (see methodology §5).
- **Prefer a staging environment** with seeded test data so authenticated and
  destructive-leaning tests don't touch real customers.

Without credentials, say so in the report and scope the engagement to what the
unauthenticated surface allows — don't imply coverage you couldn't reach.

## Where to go next

The detail for each phase lives in reference files. Read the one you need when
you reach that phase rather than loading everything at once:

- **`references/methodology.md`** — the OWASP WSTG test checklist, organized by
  category (info gathering, config, auth, session, authorization, input
  validation, errors, crypto, business logic, client-side). This is the core of
  the skill. Open it during the vulnerability-testing phase and work the
  categories relevant to the target.
- **`references/tooling.md`** — how to run the common tools (Burp Suite, ffuf,
  nuclei, sqlmap, Nmap, subfinder/httpx, etc.) and chain them into the workflow,
  with safe-usage notes. Open it when you need the concrete command for a step.
- **`references/post-exploitation.md`** — validating remote code execution
  (command injection, SSTI, deserialization, upload-to-webshell): proving it
  with the lightest safe signal first, reverse/bind shells and TTY upgrade when
  the engagement needs impact shown, and the safety / cleanup rules. Open it in
  the exploitation phase once you've found an RCE-class bug.
- **`references/reporting.md`** — severity rating (CVSS), what makes good
  evidence, and how to structure findings. **Always produce two reports — a
  technical one and a plain-language stakeholder summary — and deliver both as
  PDF** via `scripts/render-report.sh`. Open it in the reporting phase.
- **`references/lab-targets.md`** — legal practice targets and how to spin them
  up, plus a suggested learning path by vulnerability class. Open it when the
  user wants to practice rather than test a real target.
- **`assets/report-template.md`** — a fill-in report / finding template. Copy it
  and populate it per finding.

## Working principles

- **Confirm before you exploit.** Prove a vulnerability with the lightest
  possible proof-of-concept. Reading one row to prove SQLi beats dumping the
  whole database; an `alert(document.domain)` beats a real credential-stealing
  payload. Minimal PoC = clear evidence with the least risk to the target.
- **Stay in scope, always.** An interesting finding on an out-of-scope host is
  still out of scope. Note it, report that it exists, but don't test it without
  getting scope extended first.
- **One finding, one write-up, as you go.** Don't batch reporting to the end —
  capture the request/response, steps, and impact while the context is fresh.
- **Explain the "why" to the user.** Many users are learning. When you suggest a
  test, say what class of bug it targets and what a positive result would look
  like, so they build intuition rather than just running commands.
- **Prefer reversible, low-noise tests first.** Escalate intensity only as
  needed, and respect any rate limits in the RoE.