Web Application Penetration Testing
For CTOs, DevOps and compliance teams who need more than a scanner dump. We manually test your web application the way a real attacker would — chaining access-control, injection and business-logic flaws into demonstrable impact — and hand you a prioritized, reproducible report your engineers can act on immediately.
What we test
Injection (SQL / NoSQL / OS command)
Error-based, boolean/time-based blind, second-order and stacked SQLi, plus NoSQL operator injection and OS command injection in every user-influenced parameter, header and JSON field (WSTG-INPV-05/06, A03).
Cross-Site Scripting (reflected, stored, DOM)
Reflected and persistent XSS plus client-side DOM sinks (innerHTML, document.write, eval, location) reached through source-to-sink data flow, with CSP-bypass assessment (WSTG-INPV-01/02).
Broken Access Control & IDOR
Horizontal and vertical privilege escalation, insecure direct object references, forced browsing to unlinked endpoints, and missing function-level authorization on state-changing actions (WSTG-ATHZ, A01).
Authentication & session management
Credential stuffing and lockout gaps, weak password/MFA flows, predictable or non-rotated session tokens, session fixation, and insecure JWT handling (alg=none, weak secret) — WSTG-ATHN/SESS, A07.
CSRF & SSRF
Missing/forgeable anti-CSRF tokens and SameSite gaps on state-changing requests, and server-side request forgery reaching internal services or cloud metadata (169.254.169.254) — WSTG-SESS-05, A10.
Business-logic abuse
Workflow and state-machine bypass, price/quantity tampering, race conditions on limited resources, coupon/refund abuse and negative-value edge cases that automated tools cannot infer (WSTG-BUSL, A04).
Unrestricted file upload & path traversal
Content-type and extension bypass to web-executable payloads, directory traversal and local file inclusion, and archive/zip-slip handling (WSTG-BUSL-09, WSTG-ATHZ-01).
Insecure deserialization & vulnerable components
Unsafe object deserialization leading to RCE, plus fingerprinting of outdated frameworks/libraries against known CVEs and their reachable attack surface (A08, A06).
Methodology
- 1
Pre-engagement & scoping
We define targets, roles, test accounts, rate limits and rules of engagement in writing, agree a maintenance/rollback window for intrusive checks, and confirm signed authorization before any traffic is sent (PTES pre-engagement).
- 2
Reconnaissance & mapping
Passive and active discovery of the full application surface — routes, APIs, hidden parameters, JS bundles and SPA endpoints — building the coverage map that WSTG-INFO drives testing from (PTES intelligence gathering).
- 3
Threat modeling
We rank entry points, trust boundaries and high-value assets (auth, payments, PII, admin) to focus effort where a breach hurts most, per PTES threat modeling and OWASP’s risk-based approach.
- 4
Manual testing & exploitation
Hands-on testing across every WSTG category, then safe proof-of-concept exploitation and controlled chaining to establish real, demonstrable impact rather than theoretical findings (PTES exploitation).
- 5
Post-exploitation & impact analysis
For confirmed issues we assess blast radius — data reachable, privilege gained, lateral movement — and rate each finding with CVSS v3.1 and a business-impact narrative (PTES post-exploitation).
- 6
Reporting & re-test
A prioritized report with reproduction steps, evidence and concrete remediation; a technical debrief with your engineers; and a free re-test to verify every fix closed the issue (PTES reporting).
Standards & references
What you get
- Executive summary — A one-page, non-technical view of risk posture, key findings and business impact for leadership and auditors.
- Technical findings report — Each vulnerability with CVSS score, affected endpoints, step-by-step reproduction, request/response evidence and a WSTG/CWE reference.
- Prioritized remediation plan — Fixes ranked by risk and effort, with concrete code/config guidance your developers can implement directly.
- Attestation letter — A signed statement of the testing performed and scope, suitable for clients, partners and compliance (SOC 2, ISO 27001, PCI DSS) evidence.
- Free re-test & verification — After you remediate, we re-test the confirmed findings and issue an updated report showing what is closed.
FAQ
How long does a web application pentest take?+
A typical application takes 5–10 business days of testing plus 2–3 days for reporting, depending on the number of roles, endpoints and business workflows. After scoping we give you a fixed number of tester-days and a firm delivery date, so there are no open-ended timelines.
What do you need from us to start?+
A defined scope (URLs/hosts), test credentials for each user role, a staging or production go-ahead, and signed authorization. For thorough coverage we prefer authenticated testing with at least two accounts per role so we can properly assess access control and IDOR.
Will testing break our application or affect real users?+
We test against staging where possible and use safe, non-destructive proof-of-concepts by default. Intrusive checks (e.g. anything risking data change) are only run inside an agreed window and coordinated with your team, and we can throttle or pause on request.
Is this legal, and how is our data protected?+
Testing is performed only under a signed authorization and rules-of-engagement contract, which makes it lawful. All findings and data are handled under NDA, evidence is stored encrypted, and it is deleted on request after the engagement closes.
Do you just run automated scanners?+
No. Scanners find low-hanging fruit but miss access-control, business-logic and chained vulnerabilities — the ones that cause real breaches. Our work is primarily manual, following OWASP WSTG, with tooling used only to accelerate coverage, not to replace human testing.
Is the re-test really free?+
Yes. One round of re-testing on the findings from the original report is included, so you can prove to auditors and customers that the issues were actually remediated, not just acknowledged.