Web Application Penetration Testing
Web Application Penetration Testing
Find what your scanner can't.
Manual web app pentesting against OWASP ASVS L2/L3. Business logic flaws, multi-tenant isolation, complex auth flows — the bugs scanners miss and consultants charge $80k for.
Scanners find injection. Engineers find logic flaws.
Your SAST already catches XSS and SQL injection. The bugs that get protocols breached are different: tenant boundary violations, race conditions in business logic, auth bypasses via state confusion. Those need engineers, not regex.
- Multi-tenant isolation: cross-tenant data leakage
- Business logic: race conditions, double-spend, state confusion
- Auth flows: OAuth scope confusion, SAML XML signature wrapping
- Authorization: BOLA, IDOR, privilege escalation chains
CRITICAL IDOR via tenant_id parameter GET /api/v2/orders?tenant_id=42 → returns other tenants' orders // scanner: clean HIGH Race condition in payment retry POST /pay/retry — no idempotency key → 12 charges from 1 click // scanner: clean HIGH SSRF via webhook URL POST /webhooks {"url":"http://169.254.169.254"} → AWS IMDS credentials exposed // scanner: clean MEDIUM JWT alg confusion (RS256 → HS256) → public key used as HMAC secret // scanner: clean
OWASP ASVS, but actually executed.
Most vendors claim ASVS alignment and run a scanner. We execute every applicable verification requirement manually, document the test, and provide pass/fail evidence. Your auditor gets a real ASVS coverage map, not a checkbox.
- ASVS L2/L3 verification requirement coverage
- PTES methodology for execution
- MITRE ATT&CK mapping in findings
- CVSS 3.1 scoring with environmental adjustments
V1 Architecture 28/28 ✓ V2 Authentication 52/52 ✓ V3 Session Management 22/22 ✓ V4 Access Control 21/22 — 1 fail V5 Validation/Encoding 37/37 ✓ V6 Stored Cryptography 14/14 ✓ V7 Error Handling 9/9 ✓ V8 Data Protection 10/12 — 2 fail V9 Communications 11/11 ✓ V10 Malicious Code 9/9 ✓ V11 Business Logic 11/13 — 2 fail V12 Files / Resources 11/11 ✓ V13 API / Web Service 21/21 ✓ V14 Configuration 11/11 ✓ → 5 fails. 3 critical, 2 high. PoCs included.
What we test
End-to-end web application surface.
OAuth 2.0 / OIDC, SAML, MFA flows, password reset, account recovery, session fixation.
RBAC / ABAC, BOLA, IDOR, privilege escalation chains, multi-tenant isolation.
SQLi, NoSQLi, command injection, template injection, LDAP injection, XPath.
Race conditions, state machine flaws, double-spend, replay attacks, workflow bypass.
XSS (stored, reflected, DOM), CSRF, clickjacking, prototype pollution, supply chain.
Sensitive data in URLs, logs, error messages, debug endpoints, backup files.
Fixed-fee. Scope-based. No surprise hours.
Deliverables
What you receive at engagement end.
Executive summary, methodology, findings with severity (CVSS 3.1) and reproduction, ASVS coverage matrix, remediation guidance. Audit-ready PDF + machine-readable JSON.
Step-by-step reproduction. Burp project file. cURL commands. Where useful, a Python script. Your engineers can verify and re-verify independently.
Full OWASP ASVS L2/L3 verification map showing pass / fail / not applicable for every requirement. Auditors accept this directly as evidence.
After you fix the findings, ping us. We re-verify within 72 hours and update the evidence trail. No new SOW, no new invoice.
Sample Finding
What a finding looks like.
Endpoint: GET /api/v2/orders?tenant_id={id}
Issue: The orders endpoint accepts a tenant_id parameter that is not validated against the authenticated user's tenant association. By substituting another tenant's ID, any authenticated user can enumerate orders belonging to other tenants.
Reproduction: 1. Authenticate as [email protected]. 2. Request /api/v2/orders?tenant_id=42 (tenant B). 3. Response contains tenant B's order records.
Impact: Cross-tenant data exposure. Estimated 14M order records enumerable across 1,200+ tenants.
Remediation: Remove the tenant_id parameter entirely. Derive tenant from the authenticated session's claim. Add backend authorization check on every multi-tenant resource.
Frequently Asked Questions
Common questions, answered.
How long does a web app pentest take?
Black box, grey box, or white box?
Do you test in production?
What's in the report?
How much does a web app pentest cost?
Will the pentest impact my production users?
Do you provide retests after we fix findings?
What if you find a critical issue mid-engagement?
Can the report be public?
Do you sign customer-specific NDAs and DPAs?
How do you compare to Cobalt, HackerOne, Synack, or NetSPI?
How is web app pentesting different from a vulnerability scan?
Can your pentest satisfy our SOC 2 / ISO 27001 / PCI requirement?
Do you test multi-tenant isolation specifically?
What's the difference between OWASP ASVS L2 and L3?
What if you find nothing critical?
What is web application penetration testing
Manual security testing of your web app, by senior engineers.
Web application penetration testing is the controlled, manual security assessment of a web-facing application — its frontend, backend, APIs, authentication flows, authorization model, and business logic — to identify vulnerabilities before attackers do. Unlike automated vulnerability scanning, a real pentest is conducted by experienced security engineers who exercise creative attack patterns that scanners can't model.
The engagement combines automated tools (DAST scanners, fuzzers, proxy interceptors like Burp Suite) with deep manual analysis. Senior engineers walk authenticated and unauthenticated paths, test access control at the object and function levels, exercise auth flows like OAuth 2.0 and SAML against XML signature wrapping and token confusion, and probe business logic for race conditions, replay attacks, and state-machine flaws.
Most modern web app vulnerabilities — IDOR, BOLA, SSRF, JWT alg confusion, multi-tenant isolation bugs, OAuth scope confusion — are findings that automated tools either miss completely or generate as low-confidence noise. A web pentest is the workstream where those findings actually surface.
- Aligned to OWASP ASVS L2 / L3 verification standard
- Uses Burp Suite Pro, OWASP ZAP, Caido, semgrep, and proprietary tooling
- Black-box, grey-box, and white-box engagement options
- Reproducible PoC delivered for every finding — no theoretical vulnerabilities
Pricing & timeline
Fixed-fee engagements, scoped before signing.
Web app pentests are billed as fixed-fee engagements scoped after a discovery call — no engineer-hour metering. Pricing scales with application surface (endpoints, user roles, third-party integrations) rather than time spent. Most engagements complete within 2-4 weeks.
Deliverables
What you get from a CredShields web pentest.
1-page risk overview written for non-technical stakeholders. Suitable for board reporting and customer security questionnaires.
Pass/fail evidence per OWASP ASVS verification requirement. Auditors love this — it converts directly to control evidence.
Each finding includes severity (CVSS 3.1 with environmental), affected component, reproduction steps, PoC payload, and remediation guidance with code examples.
Working exploit code or curl commands for every issue. Your engineers can verify and validate without being security experts.
Findings mapped to SOC 2 CC6.1/6.6/7.1/7.2, ISO 27001 A.12.6.1/A.14.2.8, PCI DSS Req 6/11.3, HIPAA 164.308/164.312.
60-minute walkthrough with the senior pentester. Bring your engineering team, ask questions, plan remediation in real time.
Buyer's guide
Manual web pentest vs. automated alternatives.
| DAST scanner | Bug bounty | Manual web pentest | |
|---|---|---|---|
| Finds business logic flaws | No | Sometimes | Yes — primary value |
| Finds multi-tenant isolation bugs | Almost never | Possibly | Yes — methodical coverage |
| Finds auth bypass / SAML / OAuth flaws | No | Hit-or-miss | Yes — explicit test plan |
| False positive rate | High (often 30-50%) | Low (validated by hunter) | Zero — engineer-validated |
| Compliance acceptance | Insufficient alone for SOC 2/ISO | Mostly insufficient | Standard evidence |
| Cost | Low ($5k-$20k/yr) | Variable, hard to predict | Mid ($22k-$120k/engagement) |