Web App Pen Test Checklist

A web app pen test is a structured security exercise. A tester tries to exploit your web app the same way a real attacker would. If you are a startup founder or SMB owner running a SaaS product, you will hit the moment when a buyer asks for your latest pen test report. You need an annual web application pen test before that moment.

This checklist is written for SaaS startups, SMBs, and lean security teams. It covers what a test should cover, what to ask your vendor, and how to read the report you get back.

A web app pen test is not a vulnerability scan. A scan runs automated tools and lists CVEs. A pen test starts where the scanner stops. The tester chains weaknesses and produces proofs of compromise. The output is impact, not just inventory.

If you are new to penetration testing, the web application penetration testing overview explains what a test covers end to end. For tooling decisions, see the best penetration testing tools. If you are looking to outsource, compare the best penetration testing companies.

What does a web application pen test cover?

A web app pen test covers the application layer plus the supporting infrastructure. That means your code, your APIs, and your authentication. It also covers the web server, the app server, and the database.

The test evaluates the OWASP Top 10. It evaluates the OWASP API Security Top 10. It looks for business logic flaws. It tests authentication and session management. For most startups and SMBs, that scope is enough.

The scope of a web application pen test typically includes:

• All authenticated and unauthenticated endpoints.
• Authentication, password reset, and session management.
• Authorization and access control.
• Input validation, output encoding, and injection vectors.
• File upload, file download, and template handling.
• API endpoints (REST, GraphQL, SOAP).
• Business logic flaws specific to your application.
• Client-side code (JavaScript, content security policy).
• Configuration of the web server, application server, and supporting middleware.

Pen tests do not include reviewing the third-party services your app uses (Stripe, AWS, Auth0). Those are out of scope by default. They also do not include source code review unless you specifically scope a "white box" test.

OWASP Top 10 (2021): the foundational checklist

The OWASP Top 10 is the most widely accepted baseline for web application security. Every web application pen test should test for each of the 2021 categories. The 2025 revision is in draft and the 2021 list remains current through 2026.

A competent pen tester goes beyond automated scanning. They chain weaknesses. For example, an IDOR (A01) plus a missing rate limit (A04) plus verbose errors (A05) becomes a full account takeover chain.

Pre-engagement checklist

Most pen tests waste time because the engagement was scoped poorly. The checklist below covers what you should agree on with your tester before kickoff.

• Define the scope: production URL, staging URL, IP ranges, API endpoints, mobile apps if applicable.
• Define out-of-scope: third-party services, denial of service tests, social engineering, physical attacks.
• Provide test accounts: at least one per role (admin, customer, support agent, etc.) with valid login credentials.
• Decide on test type: black box (no info), gray box (test accounts only), white box (full code access).
• Decide on test environment: production, staging mirror, or dedicated test environment.
• Set test windows: business hours, off hours, or 24/7 with prior notice.
• Establish escalation contacts: who responds if the tester finds a critical vulnerability.
• Confirm the testing tools and IPs the tester will use, so your IDS/WAF does not block them.
• Sign authorization (Get-Out-of-Jail-Free letter) explicitly authorizing the test.
• Define the deliverable: report format, executive summary, technical findings, retest scope and timeline.

The most common scoping mistake is testing production with no warning. The tester triggers your WAF. The WAF blocks the test. You spend days debugging instead of finding bugs.

Two fixes for startups and SMBs: disable the WAF for the tester's source IPs, or test against a staging mirror.

Authentication and session management checks

Authentication is where most production breaches start. Every web application pen test should verify the authentication flow rigorously. The list below is the minimum testers should cover.

Login endpoint:

• Brute force protection: rate limiting, account lockout, CAPTCHA.
• Credential stuffing detection: known compromised credentials should be rejected.
• Username enumeration: error messages should not reveal whether an account exists.
• TLS enforcement: login pages must redirect HTTP to HTTPS.
• Password storage: passwords must be hashed with bcrypt, scrypt, or Argon2 (verified through other findings or code review).

Password reset:

• Reset token entropy: minimum 128 bits of randomness.
• Reset token single-use and short expiration (under 1 hour).
• Reset token bound to the requesting account (cannot be reused for a different user).
• Reset token sent only over secure channels (email, not SMS unless intentional).
• Account enumeration through password reset (same response whether account exists or not).

MFA:

• MFA bypass: cannot skip MFA via direct API call or session manipulation.
• MFA secret rotation when device is changed.
• Backup codes generated single-use and stored hashed.
• WebAuthn/FIDO2 support for phishing-resistant MFA.

Sessions:

• Session ID entropy: minimum 128 bits.
• Session timeout: idle timeout under 60 minutes for sensitive apps.
• Session invalidation on logout, password change, MFA enrollment change.
• HttpOnly, Secure, and SameSite=Strict (or Lax) cookie flags.
• No session fixation: new session ID issued at login.

Authorization and access control checks

After authentication, authorization is the next failure point. Every web application pen test should test authorization at the role level, the resource level, and the action level.

Role-level authorization:

• Test every role (admin, manager, regular user, support agent, anonymous) against every endpoint.
• Verify that users cannot escalate to higher roles via UI manipulation, parameter tampering, or direct API calls.
• Verify that role transitions on suspension or termination immediately revoke access.

Resource-level authorization (IDOR):

• Test direct object references in URLs and request bodies (orderId, userId, projectId).
• Verify that authenticated users cannot access other users' resources by changing the ID.
• Test sequential, predictable, and UUID-based IDs separately.

Action-level authorization:

• Verify that read-only roles cannot perform write actions.
• Verify that delete actions require additional confirmation or higher role.
• Verify that bulk operations enforce per-record authorization.

Multi-tenancy isolation:

• For SaaS apps with multiple customer organizations, verify that one organization's users cannot access another's data.
• Test the tenant ID parameter in URLs, request bodies, and API calls.
• Test cross-tenant data leakage through shared cache, shared logs, or shared storage.

Injection and input validation checks

Injection vulnerabilities remain among the most damaging web application bugs in 2026. Modern frameworks reduce the risk but do not eliminate it. Testers should verify the following inputs are validated and sanitized.

• SQL injection: every database query parameter, including search, filter, sort, and pagination.
• NoSQL injection: MongoDB, DynamoDB, and other NoSQL stores accept query operators that can be injected.
• Command injection: any input that flows to a shell command, file path, or system call.
• LDAP injection: directory queries that take user input.
• Server-side template injection: any input that flows to a template engine (Jinja, Handlebars, Liquid).
• XML external entity (XXE): any XML parser that processes user input.
• XPath injection: any input that flows to an XPath query.
• Cross-site scripting (XSS): all output rendered in HTML, JavaScript, JSON, or other contexts.
• HTTP header injection: any input that flows to a response header (Set-Cookie, Location, etc.).
• Open redirect: any redirect URL that takes user input.

Modern frameworks like React, Vue, Rails, and Django ship with default protections. They block most injection categories. But custom code, raw SQL, and integration points often bypass them. SaaS startup teams that lean on framework defaults still get burned in the bespoke parts.

API security checks

Most modern web apps are split between a SPA frontend and a backend API. The OWASP API Security Top 10 (2023) lists the most common API-specific failures. Pen testers should cover all 10.

API testing is harder than UI testing. Endpoints are not visible in the browser. Provide testers with your OpenAPI spec, GraphQL schema, or Postman collection. Otherwise they will rely on traffic interception, which misses unused endpoints.

Business logic and abuse testing

Business logic flaws are the most damaging findings. Automated tools cannot detect them. The tester has to understand your app, then think about how to abuse it. Every web app pen test should include time for this.

Examples of business logic findings to test for:

• Price manipulation in checkout (changing item price in the request).
• Quantity manipulation (negative quantities, zero quantities, large quantities).
• Currency manipulation (changing currency in the request to one with different exchange rate).
• Discount and coupon abuse (stacking, reuse beyond limits, applied to ineligible items).
• Race conditions (parallel requests to bypass rate limits or single-use restrictions).
• Workflow bypass (skipping required steps in a multi-step process).
• Time-of-check vs time-of-use (TOCTOU) bugs in account operations.
• Account creation bot abuse (mass account creation, referral abuse, free trial abuse).

A competent pen tester spends 25 to 40 percent of their time on business logic. If your tester reports zero business logic findings on a complex app, the test was probably automated-only. SMBs and SaaS founders should ask for sample findings from past clients before signing.

Reading the pen test report

A typical web application pen test report contains an executive summary, a methodology section, a findings section, and an appendix. The findings are the substance.

Each finding should include:

• Severity rating (Critical, High, Medium, Low, Informational) with CVSS score.
• Affected URL or component.
• Description of the vulnerability.
• Steps to reproduce (with screenshots or curl commands).
• Impact: what the vulnerability allows an attacker to do.
• Recommendation: how to fix it.
• References (CWE, OWASP, vendor advisories).

Reject reports that only list vulnerabilities without proof of exploitation. "Possible SQL injection on /api/search" is not a finding. "SQL injection on /api/search confirmed by extracting the users table" is a finding.

Reject reports that copy-paste scanner output. The hallmark of a real pen test is chained findings. If your report has 15 unrelated medium findings and zero chains, you bought a scan, not a pen test. Most SMB founders we talk to do not realize this until year two.

Pre-test prep in five steps

A short sequence we recommend for SMBs and SaaS startups before kicking off a test:

1. Freeze a target environment: stage the test against staging, not production, unless your contract says otherwise.
2. Define the scope in writing: in-scope domains, out-of-scope endpoints, and rules of engagement.
3. Brief the engineering team: warn on-call, mute alerts where appropriate, set a daily standup with the testers.
4. Provision test accounts: at least one per role (admin, member, read-only) for authenticated testing.
5. Confirm reporting timelines: when the draft report is due, how findings will be triaged, and who signs off on remediation.

Frequently Asked Questions

How often should I do a web application pen test?

Annually at minimum. Quarterly for high-risk applications (fintech, healthcare, identity providers). Also after any major release or architectural change.

How long does a web application pen test take?

A small SaaS application takes 5 to 10 business days of testing plus 5 days for reporting. A mid-market app takes 10 to 15 days plus 5 to 7 days for reporting. A large enterprise app takes 15 to 30 days plus 7 to 10 days for reporting.

What is the difference between black box, gray box, and white box pen testing?

Black box gives the tester nothing but the URL. Gray box gives the tester valid login credentials for each role. White box gives the tester credentials plus source code or architecture documents. Gray box is the most common and the most efficient. Black box wastes time on reconnaissance. White box helps testers find deeper bugs but costs more.

Do I need a separate pen test for my mobile app?

Yes. The mobile client introduces vulnerabilities that web testing cannot find: insecure local storage, weak SSL pinning, reverse engineering exposure, and platform-specific issues. Mobile pen tests typically cost $5,000 to $20,000 in addition to the web test.

What pen test findings does SOC 2 require me to fix?

SOC 2 does not specify a fix timeline, but auditors expect Critical and High findings to be remediated before the report is issued. Medium and Low findings can be tracked in a remediation plan and fixed over the next observation window.

Can my own engineers do the pen test?

Internal pen testing is allowed for most compliance frameworks but external pen testing is required for PCI DSS and strongly preferred by SOC 2 auditors. Run an internal test in addition to the external one if you have the talent. Do not skip the external test.

How much does a web application pen test cost in 2026?

A small SaaS application pen test costs $8,000 to $15,000. A mid-market app costs $15,000 to $40,000. An enterprise app or one with mobile and API scope costs $40,000 to $80,000 or more. Bug bounty programs are not a substitute, but they complement annual pen testing well.

Sources and further reading

• OWASP Top 10 (2021).
• OWASP API Security Top 10 (2023).
• PTES Penetration Testing Execution Standard.
• NIST SP 800-115 Technical Guide to Information Security Testing.