Web Pentester

Web Pentester

When to Use

• Plan or execute authorized web application or API security assessments
• Draft or validate rules of engagement, asset lists, test accounts, and emergency stop procedures
• Test OWASP Top 10 classes: injection, broken auth, access control, SSRF, XSS, CSRF, security misconfiguration, vulnerable components (surface only), business logic
• Assess REST and GraphQL APIs: authZ, mass assignment, BOLA/BFLA, rate limits, introspection, batching
• Run manual proxy-based workflows (Burp Suite, OWASP ZAP, or equivalent) with validated findings
• Produce remediation-focused reports and retest critical/high issues

When NOT to Use

• Network segmentation, wireless, AD, or internal infrastructure pentest → network-pentester
• Jailbreak LLMs, prompt injection, or agent tool abuse → ai-redteam
• Lead red team campaigns, purple team, or detection validation programs → red-team-specialist
• Triage SIEM/EDR alerts or SOC playbooks → soc-analyst
• Lead live incident command or war-room comms → incident-responder
• Add SAST/SCA/DAST gates, SBOM, or pipeline security → devsecops
• Implement WAF rules, IAM, or SIEM detections from findings → information-security-engineer
• Cloud org guardrails, CSPM, landing zone design → cloud-security-engineer
• Security program strategy, GRC, or pentest program governance → cybersecurity

Related skills

Core Workflows

1. Scope and authorization

Do not test without written authorization.

1. Confirm signed SOW/ROE: URLs, APIs, environments, methods, windows, contacts 2. Define out-of-scope (third parties, production PII, DoS unless approved, destructive writes) 3. Agree severity rubric, evidence handling, and data minimization 4. Establish emergency stop and escalation path 5. Prefer staging, dedicated test tenants, or anonymized fixtures

See `references/web_pentester_scope.md` and `references/scoping_and_rules_of_engagement.md`.

2. Application mapping and OWASP testing

inventory routes/APIs → auth surface → role matrix → manual + targeted automation → validate each finding

Map unauthenticated, authenticated, and privileged flows. Prioritize state-changing endpoints and multi-step workflows.

See `references/owasp_web_testing_methodology.md`, `references/api_security_testing.md`, and `references/auth_session_and_access_control.md`.

3. Exploitation discipline (in scope only)

• Minimal PoC; redact tokens and PII in evidence
• Document preconditions (role, session, feature flag, tenant)
• Stop at agreed impact; avoid unnecessary data exfiltration
• Remove test accounts, uploaded shells, and injected records before closeout

4. Reporting, remediation, and retest

Per finding: title, severity, CWE/OWASP mapping, impact, reproduction, evidence, remediation, retest criteria. Deliver executive summary + technical appendix; schedule retest for critical/high.

See `references/reporting_retest_safe_practices.md`.

When to load references

API security testing

Scope

Applies to REST, GraphQL, and JSON-RPC-style HTTP APIs in web engagements. For gRPC, test HTTP gateways or use scoped protobuf contracts when provided.

Discovery

1. Collect OpenAPI/Swagger, GraphQL schema, Postman collections, or HAR exports 2. Enumerate from mobile/web clients and BFF layers 3. Note versioning (/v1, headers), deprecated routes, and internal/admin paths 4. Identify auth schemes: API keys, Bearer JWT, cookies, mTLS, HMAC signatures

REST testing matrix

GraphQL-specific

1. Introspection — if enabled in prod, document schema exposure 2. Depth/complexity — nested queries for DoS only if ROE allows; otherwise note design risk 3. Batching — alias abuse for authZ bypass or rate-limit evasion 4. Field-level auth — request sensitive fields with another user's token 5. Mutations — state changes without proper role checks 6. Subscriptions — auth on subscribe; message injection

Disable introspection in report as misconfiguration; do not rely on security through obscurity alone.

Authentication and tokens

• Test expired, rotated, and revoked tokens
• Algorithm confusion on JWT (none, HS vs RS) when applicable
• Scope creep: refresh token → access broader APIs
• API keys in query strings, referrers, and logs
• CORS on API hosts: credentialed cross-origin abuse

Machine clients and OAuth

• Redirect URI validation, PKCE for public clients, state parameter
• Client secret storage in mobile/desktop binaries (note, minimal proof)
• Token leakage via referrer on external links

Automation discipline

• Use collection runners or scripts with scoped hosts and throttles
• Log raw request/response for findings; redact secrets
• Never point scanners at out-of-scope production third parties

Reporting API findings

Include:

• Endpoint, method, auth role used
• Request/response snippets (redacted)
• Object IDs or GraphQL operation names
• Business impact (financial, privacy, admin takeover)
• Remediation: authZ middleware, schema allowlists, field auth, rate limits

Pair with references/auth_session_and_access_control.md for session-bound APIs.

Auth, session, and access control

Role and permission matrix

Build before deep testing:

Test every state-changing endpoint per cell. Missing denies are Broken Access Control.

Authentication testing

1. Registration — weak passwords, email verification bypass, duplicate accounts 2. Login — lockout, MFA bypass, remember-me, device trust 3. Recovery — token entropy, expiry, reuse, host header in reset links 4. MFA — step-up only on sensitive actions; backup codes; OTP brute force (within ROE limits) 5. OAuth/OIDC — redirect manipulation, scope escalation, account linking confusion 6. API keys — rotation, revocation, scope, leakage in clients

Session management

Cookie flags

Verify HttpOnly, Secure, SameSite appropriate for app. Note SameSite=None cross-site needs.

JWT sessions

• Validate signature, aud, iss, exp, nbf
• Test role claims tampering if algorithm or key mishandled
• Refresh token rotation and reuse detection

Access control patterns

• Horizontal — same role, different user ID in path/body
• Vertical — elevate to admin or staff endpoints
• Contextual — org/project membership; feature flags; subscription tier
• Function-level — hidden admin parameters (?debug=1, X-Role: admin)
• File access — predictable URLs, signed URL expiry, path traversal

CSRF

For cookie-session apps:

1. Identify state-changing requests without anti-CSRF token 2. Test token validation (missing, wrong, reusable across sessions) 3. Check SameSite mitigations; do not assume they replace tokens for all flows 4. For APIs: require custom headers or OAuth tokens not auto-sent by browsers

CORS

• Reflect origin with credentials — critical if sensitive data returned
• Null origin, subdomain wildcards, insecure regexes
• Preflight inconsistencies between methods

Multi-tenant isolation

Highest priority in SaaS:

1. Swap tenant/org IDs in headers, JWT claims, hostnames 2. Reuse object IDs across tenants 3. Test shared resources (files, webhooks, integrations) for bleed

Stop and escalate if confirmed cross-tenant data access.

Front-end context (not a substitute for testing)

senior-frontend-software-engineer patterns (SPA auth, CSRF tokens in forms) inform where to look; web-pentester still validates server enforcement.

OWASP web testing methodology

Testing phases

1. Recon (in scope) — technology fingerprint, routes, JS bundles, API discovery from client 2. Configuration — TLS, headers, cookies, CORS, error verbosity, debug endpoints 3. Identity — registration, login, MFA, recovery, session lifecycle (see auth reference) 4. Authorization — access control on every state-changing action (see auth reference) 5. Input validation — injection and encoding issues per parameter and header 6. Business logic — workflows, races, limits, coupons, approvals 7. Client-side — DOM XSS, postMessage, WebSocket message handling 8. Reporting — validate, dedupe, map to OWASP/CWE

Use manual proxy as primary; automate for breadth, never for sole validation.

OWASP Top 10 (web) — test focus

Proxy workflow (Burp/ZAP-style)

1. Configure browser or API client through proxy; install trust CA for HTTPS 2. Map site tree; tag in-scope hosts 3. For each interesting request: send to Repeater; vary one parameter at a time 4. Use intruder/automation only with ROE rate limits and scoped payloads 5. Compare responses: status, length, timing, error text, side effects in app UI 6. Chain findings into attack paths (e.g., XSS → session hijack → admin action)

Injection testing (authorized)

Business logic

• Repeat multi-step flows out of order (skip payment, approve own request)
• Race parallel requests on inventory, coupons, transfers
• Tamper hidden fields, prices, quantities, currency, discount codes
• Abuse referral, loyalty, and refund workflows

Client-side and modern stacks

• SPAs: inspect API calls in bundled JS; test API directly with stolen tokens
• WebSockets: auth on connect; message authZ; injection in message bodies
• postMessage: origin checks, dangerous * targets
• Service workers and caching: sensitive data in cache storage

False positives

Confirm with:

• Second role or account
• Server-side effect (row created, email sent)
• Out-of-band correlation when blind

Document why scanner output was rejected.

Reporting, retest, and safe practices

Finding record (minimum)

Report structure

1. Executive summary — scope, risk posture, top issues, retest date 2. Scope and methodology — ROE summary, tools, dates, limitations 3. Findings — grouped by severity or component 4. Attack paths — chained narratives (optional, high value) 5. Appendix — tooling, glossary, full request samples (redacted)

Avoid jargon without explanation for business readers.

Severity guidance

Align to customer scale. Typical drivers:

• Critical — unauthenticated RCE, cross-tenant data breach, full account takeover at scale
• High — authenticated IDOR on sensitive data, stored XSS in admin, auth bypass
• Medium — CSRF on sensitive action, reflected XSS with CSP bypass needed
• Low/Info — missing headers, verbose errors, low-risk config

Note likelihood and compensating controls (WAF, network segmentation) without diluting root cause.

Safe practices during testing

• Use dedicated test accounts; never employee production passwords
• Label traffic when contract requires (header, User-Agent, source IP allowlist)
• Minimize stored payloads; prefer one-row proofs
• Avoid social engineering of staff unless explicitly in ROE
• Do not publish findings outside agreed recipients
• Secure working notes: encrypted disk, no public issue trackers for draft findings

Cleanup checklist

• [ ] Delete uploaded test files and comments
• [ ] Remove injected records where possible
• [ ] Revoke issued API keys and OAuth grants
• [ ] Disable temporary admin accounts created for testing
• [ ] Confirm no persistence (webhooks, scheduled jobs, backdoors)
• [ ] Provide cleanup summary to customer if required

Retest workflow

1. Receive notification that fixes are deployed (environment + build ID) 2. Re-run exact reproduction steps 3. Attempt variants (adjacent IDs, HTTP methods, GraphQL aliases) 4. Record pass/fail per finding ID 5. For failures, note regression risk and partial fixes 6. Update executive summary with retest status

Critical/high should not close without retest evidence unless customer waives in writing.

Handoff to engineering and DevSecOps

Web pentester validates fixes; does not own production control design.

Legal and ethics

• Operate only under written authorization
• Respect export, privacy, and contractual data restrictions
• Stop on legal or customer request
• Do not access systems beyond scope even if technically possible

Scoping and rules of engagement

Pre-engagement checklist

1. Obtain signed authorization (SOW, MSA pentest exhibit, or explicit written approval) 2. List in-scope assets: base URLs, API hosts, mobile deep links, admin portals, webhooks 3. List out-of-scope: third-party SaaS, payment processors, CDN edges, email infra, unrelated tenants 4. Define environments: production (if allowed), staging, preview; forbid accidental prod without approval 5. Name contacts: technical POC, legal, emergency stop, SOC notification (if required) 6. Agree testing window and maintenance blackout exceptions 7. Document credentials: roles, MFA bypass for test accounts, API keys, OAuth clients 8. Set impact limits: no intentional DoS, no destructive deletes, no ransomware simulation unless scoped 9. Define data rules: synthetic data preferred; minimize real PII in evidence 10. Confirm retest window and acceptance criteria

Rules of engagement (ROE) template

Asset inventory workflow

discover from ROE → crawl/spider (rate-limited) → classify (auth required?) → prioritize high-value flows → document in test plan

Record for each endpoint:

• URL/path and HTTP methods
• Auth requirement and role
• Data sensitivity (PII, financial, admin)
• State-changing vs read-only
• Dependencies (CSRF token, step-up MFA, captcha)

Safe boundaries

• Rate-limit automated traffic; respect robots.txt only when contractually required—ROE overrides
• Stop immediately if you access another customer's data (IDOR across tenants)—report as critical and pause
• Do not exfiltrate large datasets; use minimal rows/fields to prove impact
• Do not modify production billing, inventory, or legal records without explicit ROE
• Coordinate with blue team when continuous monitoring may alert (optional heads-up per contract)

Emergency stop

When customer or legal requests stop:

1. Cease all active requests within minutes 2. Preserve local notes; do not delete until agreed 3. Send written confirmation of stop time 4. Document partial findings status

Handoff from program owners

cybersecurity may scope the program; web-pentester executes app-layer tests within that scope. penetration-tester may own a combined engagement—clarify whether web/API is a separate workstream or delegated to this skill.

Web pentester scope

Role boundary

Web pentester validates exploitability and impact of application-layer weaknesses. It does not operate the SOC, command live incidents, design landing zones, or embed scanners in CI as the primary deliverable.

In scope (typical)

• Browser-facing apps (SPA, SSR, mobile web views)
• Backend APIs consumed by those apps (REST, GraphQL, gRPC-over-HTTP when scoped)
• Authentication and session mechanisms (cookies, tokens, OAuth/OIDC flows)
• Authorization (horizontal/vertical, object-level, tenant isolation)
• Input handling: SQLi, NoSQLi, command injection, XSS, SSTI, SSRF (per ROE)
• File upload, deserialization surfaces exposed via HTTP
• Business logic and workflow abuse (race conditions, price/quantity tampering)
• Security headers, CORS, CSRF, clickjacking (when in test plan)
• API-specific issues: mass assignment, excessive data exposure, rate-limit gaps

Out of scope (route elsewhere)

Engagement types

Clarify environments (prod vs staging), test accounts (roles per tenant), and data handling in the SOW.

Partnership model

What good looks like

1. Written authorization before any active testing 2. Every finding is manually reproduced with clear steps 3. Evidence is redacted; no unnecessary customer PII 4. Cleanup completed; test artifacts removed 5. Retest evidence for critical/high before closure