Web Application Penetration Testing
Manual, authenticated testing of your web application against the OWASP Web Security Testing Guide — logic flaws included, not just scanner output.
Selva Ops S.R.L.
A web application penetration test is a manual, structured attack on your application, performed with permission, to find the vulnerabilities that matter before someone else does. The work follows the OWASP Web Security Testing Guide and covers the full attack surface of a modern web application — not the subset a scanner can reach.
What actually gets tested
- Authentication — credential handling, session management, MFA implementation, password reset flows, account enumeration.
- Authorization and access control — horizontal and vertical privilege escalation, insecure direct object references (IDOR), multi-tenant data isolation.
- Injection — SQL, NoSQL, command, template, and LDAP injection at every input the application accepts, including headers and file uploads.
- Business logic — race conditions, workflow bypasses, price and quantity manipulation, abuse of intended functionality. This is where scanners find nothing and manual testing earns its cost.
- Client-side issues — XSS, CSRF, CORS misconfiguration, insecure use of postMessage and browser storage.
- Server-side issues — SSRF, insecure deserialization, file handling, cache poisoning, misconfigured security headers.
Testing is authenticated and role-based: you provide test accounts for each user role, and the assessment specifically probes what each role can reach that it should not.
Grey box by default
Most engagements run grey box — you share documentation, an architecture overview, and test accounts. It produces deeper coverage per testing day than black box. If your threat model calls for a pure external black-box view, that is available; if you want maximum depth, pair the pentest with a source code security audit.
When to test
Before a major release, after a significant architecture change, when a customer or auditor requires it (see SOC 2 and PCI DSS), or on an annual cycle. Retesting of fixed findings is included — the goal is a closed loop, not a PDF.
What you receive
- A report with reproduction steps, evidence, and severity ratings for every finding
- Remediation guidance written for the engineers who will fix the issues
- An executive summary a non-technical stakeholder can read
- Retest of fixed findings and an updated report
- An attestation letter suitable for customers and auditors
Standards and references
Compliance context
FAQ
- How long does a web application penetration test take?
- Most single-application engagements run one to three weeks of testing depending on the size of the application, the number of user roles, and the depth of business logic. Scoping settles this before any contract is signed.
- Do you test in production or staging?
- Either. A staging environment that mirrors production is preferred because testing can be more aggressive. If only production is available, testing is adjusted to avoid disruption and destructive checks are excluded or coordinated.
- Is this an automated scan?
- No. Tooling assists coverage, but every finding is manually verified and the core of the work — access control, business logic, chained attacks — is human testing that scanners cannot perform.