Web Pentest

Web Pentest — Live Web Application Testing

Structured black-box / grey-box penetration testing of a live web application against an authorized target. Pairs with recon (which maps the surface) and complements owasp-audit (which reads the source). Use recon first; use this once you have a target list and credentials (or guest access).

Authorization Check

Before touching the target, confirm: 1. Written authorization for this specific application (pentest engagement, bug bounty in-scope domain, CTF/lab, your own asset) 2. The application is currently in scope and live (not deprecated, not under maintenance freeze) 3. Test credentials provided (if grey-box), or guest access confirmed (if black-box) 4. Out-of-scope items documented — production user data, payment flows, social engineering, DoS

If anything is unclear, ask before proceeding. Never assume authorization.

Methodology

Follows the OWASP Web Security Testing Guide (WSTG) structure. Each phase produces evidence; document everything as you go.

Phase 1: Configuration & deployment

Goal: understand what's running and how it's exposed.

• HTTP headers — pull with curl -I and curl -I -H "Origin: https://evil.com":
• Server, X-Powered-By revealing stack
• HSTS, CSP, X-Frame-Options, X-Content-Type-Options presence and values
• CORS — Access-Control-Allow-Origin reflection without an allow-list, Allow-Credentials: true paired with *
• TLS — testssl.sh https://target or sslyze --regular target
• Backups / configs exposed — /.git/, /.env, /backup.sql, /web.config, /server-status, /.aws/credentials
• Default admin paths — /admin, /administrator, /manage, /console, /actuator/, /_debug/, /swagger, /graphql, /.well-known/
• Robots.txt and sitemap.xml — often list non-indexed but accessible endpoints
• Subdomain & host header testing — does the app behave differently when sent Host: internal.target.com?

Phase 2: Identity management

Goal: understand who can be created, how, and with what privileges.

• Registration — can you self-register? Does the role default to anything other than "user"?
• Username enumeration via differential responses on signup ("email already exists"), login ("user not found" vs "wrong password"), password reset ("we sent an email" vs "no such user")
• Account provisioning — does a verification email arrive? Can it be skipped? Does the reset link expire? Does the reset link tie to the original session?
• Account lockout vs rate-limit — does 100 failed logins lock the account (denial of service vector) or just slow down (good)?

Phase 3: Authentication

Goal: break in as someone you shouldn't be.

• Login form — is HTTPS enforced? Are credentials sent in URL params (logged everywhere)?
• Password policy — minimum length / complexity / breach-database check (haveibeenpwned API)
• MFA — required for admin / privileged users? Bypass paths (recovery code, "remember this device" cookie persistence, downgrade to SMS)?
• Session token — entropy looks high? Cookie has HttpOnly, Secure, SameSite=Lax or Strict?
• Session fixation — does the session ID rotate on login? Pre-auth session ID still valid post-auth?
• "Remember me" — long-lived token in a separate cookie; revocable on logout from all devices?
• Logout — does it actually invalidate the session server-side? (Test by replaying the cookie post-logout.)
• Password reset — token format, expiration, single-use, host-header poisoning (Host: evil.com in the reset email link)
• OAuth flow — PKCE used? state parameter validated? redirect_uri strictly matched (not prefix-matched)?

Phase 4: Authorization (the highest-yield phase)

Goal: access things you shouldn't.

Horizontal privilege escalation (IDOR / BOLA):

• Sign in as user A. Get a resource that belongs to user A. Note the ID.
• Sign in as user B. Try to access user A's resource by ID — direct fetch, in the body of an update, as a foreign key in another operation.
• Watch for response codes — 200 (bad), 403 (good), 404 (good if all unauthorized requests return 404; bad if your own 404 looks different)
• Try every endpoint that takes an ID — GET /users/:id, POST /users/:id/..., DELETE /users/:id, GET /api/users/:id/orders, GraphQL user(id: ...)

Vertical privilege escalation (BFLA):

• Identify admin-only routes (from /admin/* exploration, from JS bundle strings, from Burp's site map)
• Hit them as a regular user. 403 (good), 200 (very bad)
• Check for verb tampering — DELETE /admin/users/x blocked, but POST /admin/users/x/delete works
• Mass assignment — registration endpoint that accepts { role: "admin" } because it does User.create(req.body) without filtering

Tenant isolation (multi-tenant SaaS):

• Create org A with user U1. Create org B with user U2.
• As U1, try every URL that includes the org/tenant ID and swap it to org B's. Expect 403 / 404 on every one. A 200 is a tenancy break.

Phase 5: Session management

• Session token in URL? Anywhere logged → access logs leak it
• Concurrent sessions allowed? Should be configurable / loggable
• Token after password change — invalidated everywhere? (Test by changing password in browser 1 and replaying browser 2's cookie.)
• CSRF protection — synchronizer token, SameSite cookie, custom request header? Test by forging a request from a different origin

Phase 6: Input validation

For each input — URL params, query strings, headers, JSON bodies, file uploads:

• XSS — reflected (in error pages, search results, <title> injection), stored (in profile fields, comments, file names), DOM (look at JS sinks like innerHTML, eval, location)
• Payload bank — see owasp-audit Verify Fixes XSS payloads
• SQLi — ' OR 1=1 --, time-based blind ('; SELECT pg_sleep(5)--), error-based, UNION-based
• Modern stacks usually use parameterized queries; look for the one endpoint that didn't get the memo
• Command injection — anywhere file names, image processing, PDF generation, or shell-out happens
• SSRF — webhook URLs, image-fetch, PDF render — see owasp-audit A10 bypass matrix
• XXE — XML inputs in SOAP / SVG-upload / DOCX-import paths
• Server-side template injection — {{7*7}} in a name field renders 49? You're in
• Open redirect — see owasp-audit A01 with control-byte rejection
• Insecure deserialization — base64-decode any opaque tokens and look for serialized format markers (O: for PHP, \xac\xed for Java, cos\nsystem for Python pickle)

Phase 7: Error handling

• Stack traces visible in 500 responses
• Database errors leak schema (table names, column names)
• File paths leak server filesystem layout
• Different errors for valid vs invalid usernames (enumeration)
• /health / /status / /metrics / /actuator/* exposed

Phase 8: Business logic

The category most scanners can't touch. Look at what the app is supposed to do and ask "what if I do that, but wrong?"

• Race conditions — submit the same coupon code 100× concurrently; can you redeem it more than once?
• Negative numbers — can you transfer -100 and credit yourself?
• Out-of-order workflows — can you complete step 4 before step 2?
• Quota bypass — free tier limits enforced server-side or just in the UI?
• Workflow approval — can you approve your own request by tampering with approver_id?
• File upload — can you upload an .html and have the server serve it with Content-Type: text/html?

Phase 9: Client-side

• JS bundle review — view-source: / DevTools, look for inline secrets, API keys, internal endpoint hints
• CSP — try to inject a <script> and see if it's blocked
• Browser storage — what's in localStorage / sessionStorage / IndexedDB? Tokens? PII?
• Cross-origin — can postMessage from your origin reach the app's window without origin check?

Tooling

• Burp Suite Community (free) — proxy, repeater, intruder (rate-limited), decoder
• Burp Suite Pro — scanner, faster intruder, session handling rules
• OWASP ZAP — free alternative, active scanner, fuzzer
• ffuf / feroxbuster / gobuster — directory and parameter brute-forcing
• sqlmap — SQLi exploitation (use carefully; can be noisy and destructive — --risk=1 --level=1 to start)
• dalfox / XSStrike — XSS scanners (high false-positive; use as a starting point)
• nuclei — template-driven vulnerability scanner; the templates themselves are excellent reading
• curl / httpie — repeatable manual requests; everything you find should reduce to a curl command

Output Format

# Web Application Pentest Report
## Target: [target name and scope]
## Engagement window: [start - end]
## Methodology: OWASP WSTG
## Date: [date]

### Executive summary
[2-3 paragraphs — overall posture, top 3 critical findings, business impact]

### Findings
| ID | Severity | OWASP | CWE | Title |
|----|----------|-------|-----|-------|

### Per-finding detail
#### [SEVERITY] [Title]
**Endpoint:** `METHOD /path`
**OWASP / CWE:** WSTG-XXX / CWE-XXX

**Description:** [what + why it matters]

**Proof of concept:**
[curl / Burp request showing the issue, minimal viable repro]

**Observed response:**
[response excerpt showing the issue]

**Remediation:**
[concrete fix + reference to owasp-audit or api-audit if applicable]

**Risk rating:** [Critical / High / Medium / Low / Info — with rationale]

**Verification:** [what to re-test after fix]

### Out-of-scope / not tested
[Anything skipped, with reason]

### Recommendations
[Prioritized 30/60/90 day fixes]

Boundaries

• Stay strictly within the authorized scope — never test adjacent systems, subdomains, or third-party services without explicit confirmation
• Rate-limit your own testing — Burp Intruder at 100 req/s for hours is indistinguishable from a DoS attack
• Never modify or destroy real user data — test on test accounts you own, or test data you created
• If you find evidence of active compromise (someone else's webshell, exfiltration in progress), STOP testing and notify the user immediately
• Refuse requests to test systems without authorization
• Refuse to weaponize findings — proof-of-concept is the minimum viable demonstration, not a working exploit kit
• For DoS / availability testing, get explicit written approval naming the maintenance window
• For social engineering / phishing tests, scope must explicitly name this — it is not "in" pentest scope by default

References

• OWASP Web Security Testing Guide (WSTG) — canonical methodology
• OWASP Application Security Verification Standard (ASVS) — checklist version
• PTES (Penetration Testing Execution Standard)
• Bug Bounty Methodology (Jason Haddix / TBHM)
• PortSwigger Web Security Academy — free training labs
• HackTricks (book.hacktricks.xyz) — technique reference (verify against fresh sources; HackTricks aggregates community knowledge of varying quality)