Web Application Testing
How ModernPentest tests websites and web applications
Overview
When you enable the web surface for your application, ModernPentest builds an asset map of your site and reasons over it to decide what to attack. Recon maps the application, the auditor decides what's worth testing, and provers confirm each issue by exploiting it.
How a web pentest works
Reconnaissance
The recon agent crawls your application — executing JavaScript, following authentication, discovering pages, forms, APIs, and the services behind them — and assembles them into an asset map.
Auditing
The auditor reads the whole graph and emits prioritized investigations across access control, injection, authentication, and business logic.
Proving
Provers confirm each investigation by actively exploiting it, capturing a reproducible proof of concept and chaining from what they confirm.
Consolidation & Reporting
Findings are deduplicated, validated, enriched with CVSS/CWE and framework-specific remediation, and compiled with SOC 2 mapping.
Reconnaissance
The recon agent performs the first pass over your application, building the asset map:
What It Discovers
- Endpoints - All accessible pages and routes
- Technologies - Frameworks, libraries, and versions
- Authentication - Login flows, session management
- Forms and Inputs - All user input points
- APIs - Backend endpoints called by the frontend
- Sensitive Areas - Admin panels, user data endpoints
Intelligent Crawling
Unlike traditional crawlers, our agent:
- Executes JavaScript - Discovers dynamically rendered content
- Follows authentication flows - Tests both logged-in and logged-out states
- Understands context - Recognizes e-commerce vs admin vs user areas
- Prioritizes intelligently - Focuses on high-value targets first
Auditing: deciding what to attack
Rather than running every check against every endpoint, the auditor reads the whole asset map and decides what each asset actually warrants. For a typical web application with a shopping cart, user profiles, and admin areas:
| Asset group | What the auditor probes for |
|---|---|
/auth/*, /login | Session security, JWT flaws, credential stuffing, login bypass, XSS in forms |
/cart/*, /orders/* | IDOR between users, price manipulation, injection, business logic flaws |
/profile/*, /settings/* | Horizontal privilege escalation, XSS in profile fields, session hijacking |
/admin/* | Vertical privilege escalation, admin bypass, exposed debug endpoints |
/search, /api/* | SQL/NoSQL injection, SSRF, information disclosure |
Each row becomes one or more investigations the auditor hands to a prover to confirm by exploitation.
Why whole-graph auditing
- Context-aware - The auditor knows how each asset connects before choosing an attack
- Deep coverage - Effort concentrates on assets that actually warrant it
- Chaining - Confirmed findings feed back to the auditor, which pursues second-order attacks
- No wasted work - Low-value surface isn't blindly re-scanned
Consolidation
After provers finish, we consolidate findings:
Deduplication
Multiple agents may find related issues. For example:
- XSS in
/search?q=and/products?filter=are separate findings - XSS in the same parameter found twice is deduplicated
Validation
Each finding is validated for:
- Real exploitability - Can it actually be exploited?
- Evidence quality - Is the proof clear?
- False positive check - AI reviews for accuracy
Enrichment
Findings are enhanced with:
- CVSS score - Industry-standard severity rating
- CWE reference - Common Weakness Enumeration
- Remediation steps - Framework-specific fix guidance
- Related findings - Links to similar issues
What We Test
OWASP Top 10 (2021) Coverage
| Category | What We Check |
|---|---|
| A01 - Broken Access Control | IDOR, privilege escalation, forced browsing |
| A02 - Cryptographic Failures | Weak encryption, data exposure |
| A03 - Injection | SQL, NoSQL, OS command, LDAP, XSS |
| A04 - Insecure Design | Business logic flaws |
| A05 - Security Misconfiguration | Default configs, debug modes, headers |
| A06 - Vulnerable Components | Outdated libraries, known CVEs |
| A07 - Authentication Failures | Weak passwords, session issues |
| A08 - Software Integrity | Code injection, unsafe deserialization |
| A09 - Logging Failures | Missing audit trails |
| A10 - SSRF | Server-side request forgery |
Beyond OWASP
- Business logic vulnerabilities
- Race conditions
- Information disclosure
- Client-side vulnerabilities
- File upload issues
Platform-Specific Testing
Our agents automatically detect platform usage and enable additional checks—no configuration required:
| Platform | Auto-Detected Via | Additional Checks |
|---|---|---|
| Supabase | URL patterns, SDK usage | RLS policies, storage buckets, edge functions |
| Firebase | Config objects, SDK imports | Firestore rules, RTDB permissions, storage rules |
| Vercel/Next.js | Headers, deployment patterns | NEXT_PUBLIC_ exposure, API routes, middleware |
| Convex | Client configuration | Function permissions, database access |
If you add one of these platforms to your project later, recon detects it automatically during the next pentest and tags the asset so the auditor can target it. See Reconnaissance for details.
Combined Surface Testing
Most modern applications have both web and API surfaces that share users, data, and business logic. When you configure both surfaces, we test them in parallel and consolidate findings.
Web Surface and API Surface testing run simultaneously, then merge in the Consolidation phase:
- Unified findings — Vulnerabilities from both surfaces in a single report
- Cross-surface vulnerabilities — Issues that span both surfaces are identified and linked (e.g., an API endpoint with missing auth that the web app relies on)
- Complete coverage — No gaps between what the frontend exposes and what the backend accepts
Next Steps
Last updated: June 14, 2026