web-app-security-inspection

name	web-app-security-inspection
description	Aggressive red-team inspection of authorized web applications, SPAs, and APIs. Focus on finding high-severity issues (especially authorization, business logic, and account takeover class) using browser automation, HTTP manipulation, and state comparison. Designed for speed and impact — form attack hypotheses quickly and test them hard.
metadata	{"short-description":"Red-team web app hunting — authz, business logic, APIs, and client-side attacks","category":"vulnerability-research","priority":"critical"}

Web App Security Inspection (Red Team Edition)

Your job is to break the web application's security boundaries as efficiently as possible.

This is the offensive counterpart to code review. While code-vulnerability-review looks at source, this skill looks at the live (or locally captured) application from an attacker's perspective — what an authenticated or unauthenticated user can actually reach and abuse.

Red Team Philosophy

• Hypothesis first, exploration second. Don't just map the app. Constantly ask: "What can I break with this?"
• Prioritize high-value classes: Broken access control (horizontal/vertical), business logic flaws, authentication/session issues, and high-impact API problems.
• Test states aggressively. The difference between "works for owner" and "works for anyone" is often the entire finding.
• Use subagents for parallel role/tenant testing when safe and within scope.
• Move fast from reconnaissance to mutation. The goal is not beautiful documentation — it's finding bugs that pay.

Core Attack Workflow

1. Quick Recon + Hypothesis Generation

   • Load the app in different roles/tenants/states.
   • Map key workflows (especially anything involving money, data access, admin actions, or cross-user interaction).
   • Immediately form hypotheses: "This object ID is probably not properly authorized", "This endpoint might accept direct calls", "The role check is probably only client-side".

2. State Comparison Testing (Your Best Weapon) Always test the same action across different states:

   • Owner vs Non-owner
   • Tenant A vs Tenant B
   • Standard user vs Admin
   • Authenticated vs Anonymous
   • Fresh session vs old/revoked token
   • Different roles within the same account

3. API & Direct Call Testing

   • Capture requests from the UI, then replay/modify them directly (change IDs, methods, headers, bodies).
   • Test for IDORs, mass assignment, method tampering, and missing server-side checks.
   • For GraphQL: test field-level authz, introspection, and query complexity.

4. Business Logic Abuse

   • Look for race conditions, replay attacks, negative values, quota bypass, workflow skipping, coupon/invite abuse, etc.
   • Test what happens when you do things out of order or in parallel.

5. Client-Side & DOM Attacks

   • DOM XSS, postMessage issues, prototype pollution, CSP bypasses, storage poisoning.
   • Third-party script trust boundaries.

6. Validate & Escalate

   • Once you have a solid lead, document the minimal reproduction and promote it in finding-tracker.
   • Strong findings → exploit-chain-analysis or triage-verifier.

High-Value Target Areas (Prioritize These)

• Authorization everywhere — object IDs, nested resources, admin actions, exports, bulk operations, hidden endpoints.
• Authentication & Session — login flows, MFA bypass, token handling, session fixation, OAuth state/nonce issues, account takeover primitives.
• APIs & GraphQL — direct API access, field-level authorization, rate limiting on sensitive actions, excessive data exposure.
• Business Logic — anything involving money, limits, approvals, invites, quotas, or workflows.
• File & URL Handling — uploads, imports, URL fetchers, previews (SSRF, path traversal, stored XSS vectors).
• Client-Side Trust — postMessage, service workers, storage, CSP, third-party integrations.

Using Playwright in This Environment

The workspace has Playwright pre-installed. Use it for:

• Headed exploration and screenshot evidence
• Network interception and request mutation
• Storage inspection (cookies, localStorage, sessionStorage)
• Emulating different devices/viewports
• Capturing HAR files for later analysis

Prefer existing capture scripts in programs/*/scripts/ when they exist (many programs already have good ones for login flows, browsing, etc.). Extend them rather than starting from zero.

For maximum control, launch with a persistent context and CDP debugging when needed.

Handoffs (Stay Aggressive)

• Solid authz or logic finding → finding-tracker immediately
• Multiple related issues that compose → exploit-chain-analysis
• Needs clean reproduction kit + negative controls → triage-verifier
• Source-level root cause or patch review → code-vulnerability-review (point to the exact files in the decompile or source tree)
• Parser or complex input handling → fuzz-harness-builder

Output Expectations

When you find something real, produce:

• Clear title and severity
• Affected surface (URL, API endpoint, flow)
• Actor/state required
• Exact reproduction steps (minimal)
• Evidence (requests/responses, screenshots, console output, storage values)
• Impact statement
• Suggested fix direction

Don't bury good findings in "potential" language if you have working reproduction across states.

Bottom Line

Web applications are full of authorization and logic bugs that are extremely high value on bug bounty programs.

This skill should feel like a rapid, state-aware attack engine — not a slow, comprehensive security audit.

Form hypotheses. Test states. Mutate requests. Find the gaps. Move the good ones into the tracker and keep hunting.

The more aggressive and systematic you are with state comparison and direct API testing, the faster you'll find the issues that actually matter.