Pentesting Web Apps

Web App Pentesting

Use this skill when the only provided input is the target web application's base URL and you are explicitly authorized to test it.

Input Contract

• Accept exactly one required input: the base URL of the web app under test.
• Derive scope from that URL unless the user explicitly expands it.
• Stay inside the target origin and closely related subpaths unless the user authorizes additional domains.
• Record every finding with the exact URL, request method, parameters, user role used, and observed impact.

Preferred Tooling

Prefer free tools, with an open-source-first approach:

Start with Playwright and ZAP because they can cover most discovery and validation tasks from a single URL input.

Engagement Flow

1. Normalize the provided URL and confirm the scheme, host, and reachable entrypoint.
2. Crawl the application to build a route inventory of pages, APIs, forms, parameters, and client-side requests.
3. Identify authentication surfaces such as login forms, session cookies, JWTs, password reset, magic links, and "remember me" behavior.
4. Probe input points for common injection classes with safe, targeted payloads and confirm any suspicious behavior with a second method.
5. Exercise business logic and authorization boundaries, especially object identifiers in paths, query strings, request bodies, and GraphQL variables.
6. Summarize findings by severity, reproduction steps, evidence, and remediation guidance.

Crawler / Spider

Goal: map the application's reachable URL structure and likely hidden endpoints from the starting URL.

• Use Playwright to walk the visible UI, capture navigation paths, collect forms, and note XHR/fetch requests.
• Use OWASP ZAP spider and AJAX spider against the same origin to discover server-rendered and JavaScript-driven routes.
• Use ffuf or feroxbuster for low-noise content discovery against common directories, API prefixes, and backup file names when appropriate.
• Build an inventory that includes:
  • Pages and API endpoints
  • HTTP methods observed
  • Query, body, and path parameters
  • Authenticated versus unauthenticated reachability
  • File upload surfaces
  • Hidden or unlinked endpoints found via scripts, manifests, sitemaps, or robots.txt

Auth Analysis

Goal: test whether authentication and session handling can be bypassed, weakened, or reused incorrectly.

• Identify all state tokens: session cookies, JWTs, CSRF tokens, device tokens, and "remember me" cookies.
• For JWTs:
  • Decode header and claims, verify algorithm choice, and check for weak secrets or insecure verification patterns.
  • Review expiration, issuer, audience, subject, privilege claims, and token revocation behavior.
  • Check whether modified claims are rejected server-side.
• For sessions:
  • Test whether session identifiers rotate after login, privilege changes, and logout.
  • Check whether old sessions remain valid after password reset or logout.
  • Confirm cookies use secure attributes such as HttpOnly, Secure, and appropriate SameSite.
• For "remember me":
  • Determine whether the token behaves like a long-lived password substitute.
  • Check revocation, device binding, expiration, and whether theft of the token grants full account access.
• For session hijacking risk:
  • Reuse captured session material in a fresh browser context and confirm whether reauthentication is required for sensitive actions.
  • Verify that elevated actions are protected by current-session checks and not only by possession of a stale cookie or token.

Injection Probes

Goal: run automated, targeted checks against discovered inputs and validate the highest-signal findings.

• Prioritize high-value input points:
  • Search boxes
  • Login and password reset fields
  • Profile and settings forms
  • Filter, sort, and export parameters
  • JSON and GraphQL bodies
  • File upload metadata
• Check for:
  • SQL injection
  • Cross-site scripting (stored and reflected)
  • Server-side request forgery
• Use ZAP, Playwright-driven form submission, and focused follow-up tools such as sqlmap and Dalfox only on confirmed candidate parameters.
• Correlate results across at least two observations before reporting a confirmed vulnerability, such as:
  • Application error behavior
  • Response timing changes
  • Out-of-band interaction evidence where authorized
  • Rendered payload reflection or execution

Logic Tester

Goal: detect broken access control and business-logic flaws, especially IDOR-style issues.

• Enumerate object references in URLs, forms, JSON bodies, and client-side API calls:
  • user_id
  • org_id
  • project_id
  • invoice, document, ticket, or report identifiers
• Replay the same request while changing one identifier at a time.
• Compare responses across:
  • Unauthenticated context
  • Low-privilege account
  • Higher-privilege account when authorized for role testing
• Look for evidence of broken authorization:
  • Access to another user's record
  • Partial metadata leakage
  • Writable actions on another tenant's resources
  • Inconsistent authorization between UI and API
• Also test workflow flaws such as skipping required steps, reusing expired links, or performing state transitions out of order.

Reporting Expectations

For each finding, provide:

• Title and severity
• Affected URL or endpoint
• Preconditions and account role used
• Step-by-step reproduction from the supplied URL
• Evidence of the observed behavior
• Security impact
• Clear remediation guidance

Safety Rules

• Only assess systems you are explicitly authorized to test.
• Prefer low-impact checks first and avoid destructive actions unless the user explicitly requests them.
• Rate-limit aggressive crawling and fuzzing to reduce service disruption.
• Stop and ask for clarification if the discovered scope expands beyond the originally supplied URL.

Scripts

Ready-to-use helper scripts are in the scripts/ directory. They default to a safe dry-run mode that writes a plan and expected outputs; pass --execute to actually run the available tools.

Example workflow:

# Review the command plan first
bash scripts/run-assessment.sh https://example.com ./findings

# Execute the crawl and auth steps
bash scripts/crawl-surface.sh --execute https://example.com ./findings/crawl
bash scripts/auth-analysis.sh --execute https://example.com ./findings/auth

# Probe query parameters and ID-like URLs
bash scripts/injection-probes.sh https://example.com/search?q=test ./findings/injection
bash scripts/logic-tester.sh --cookie-header "session=..." https://example.com/api/users/42 ./findings/logic