Web Application Penetration Testing

Most web application breaches do not come from an unpatched library. They come from a user who can change an ID in a request and read somebody else's data, a checkout flow that can be replayed at a different price, or a password reset that hands over an account. Automated tools do not find those, because finding them requires understanding what your application is supposed to do.

Our web application testing is manual, performed against every user role you have, and mapped to the OWASP Web Security Testing Guide (WSTG) and the Application Security Verification Standard (ASVS). Tooling is used for discovery and coverage; the findings are human.

What we test

• Broken access control — insecure direct object references, horizontal and vertical privilege escalation, forced browsing, tenant isolation failures in multi-tenant SaaS
• Authentication and session management — MFA bypass, password reset poisoning, JWT signature and claim flaws, session fixation, token lifetime and revocation, SSO and OAuth flow abuse
• Injection — SQL and NoSQL injection, OS command injection, server-side template injection, LDAP and XPath injection, XXE
• Business logic — price and quantity manipulation, workflow and state bypass, race conditions, coupon and referral abuse, replay of one-time actions
• Server-side request forgery — including cloud metadata access and internal service pivoting
• Client-side — stored, reflected and DOM-based XSS, CSRF, clickjacking, postMessage abuse, prototype pollution, secrets and endpoints exposed in JavaScript bundles
• File handling — unrestricted upload leading to code execution, path traversal, archive extraction flaws
• Configuration and infrastructure — CORS misconfiguration, security headers, TLS configuration, exposed admin and debug interfaces, verbose errors, vulnerable and outdated components
• Rate limiting and abuse — credential stuffing resistance, enumeration, resource exhaustion

Testing approach

We test gray-box by default: you provide credentials for each role, and we test what an authenticated attacker can reach as well as what an anonymous one can. Black-box testing is available where you want to simulate an external attacker with no prior knowledge, and white-box testing pairs the application test with a source code review for deeper coverage of the same code paths.

Critical and high-severity findings are reported to your team the day we confirm them, with reproduction steps, so remediation can start before the report is written.

Who it is for

SaaS platforms preparing for SOC 2 or renewing it, e-commerce and payment applications in PCI DSS scope, healthcare applications handling ePHI, fintech platforms under NYDFS Part 500, and any team whose enterprise prospects have started asking for a recent third-party penetration test before they sign.

Frequently asked