Web Application Penetration Testing Checklist for Startups

Every startup reaches a point where a penetration test becomes unavoidable. Maybe a prospective enterprise customer included it in their vendor security questionnaire. Maybe your compliance advisor told you SOC 2 requires it. Maybe a security-conscious investor asked about your last assessment. Whatever the trigger, the first web application penetration test is a milestone that many startup teams approach with uncertainty.

Having worked with hundreds of startups across the San Francisco Bay Area, from pre-revenue Y Combinator companies to Series C scale-ups, CyberGuards has developed a practical checklist that demystifies the penetration testing process. This is not a theoretical exercise. It is a battle-tested guide built from real engagements with real startups facing real security challenges.

Whether your team is three engineers in a SoMa co-working space or fifty developers spread across multiple offices, this checklist will help you prepare for, execute, and get maximum value from your web application penetration test.

Phase 1: Pre-Engagement Preparation

The work that happens before a single test is executed often determines the quality of the entire engagement. Proper pre-engagement preparation ensures that the penetration testing team can maximize their time on actual testing rather than troubleshooting access issues or clarifying scope.

Define the Scope

Scope definition is the single most important pre-engagement activity. An unclear scope leads to missed vulnerabilities, wasted time, and disputes about deliverables. Be explicit about what is in scope and what is out of scope.

• Target URLs and domains: List every domain, subdomain, and URL path that should be tested. Include staging environments if they mirror production. Do not assume the testing team will discover all your subdomains on their own.
• Application features: Enumerate the major features and user workflows that should receive focused attention. If your payment processing flow is business-critical, say so explicitly.
• User roles: Document every user role in your application and provide test accounts for each. A penetration test that only examines the anonymous user experience will miss the majority of your attack surface.
• Third-party integrations: Identify integrations that are in scope (your API that connects to Stripe) versus out of scope (Stripe's infrastructure itself). This prevents confusion and potential legal issues.
• Excluded targets: Explicitly list any systems, endpoints, or attack types that should not be tested. Production databases with real customer data, third-party services you do not own, and denial-of-service testing are common exclusions.

Prepare the Environment

A well-prepared testing environment eliminates the most common source of delays during engagements. Address these items before the engagement begins:

• Provision dedicated test accounts for each user role with realistic data and permissions
• Whitelist the testing team's IP addresses in your WAF, rate limiter, and any other automated blocking systems
• Ensure the testing environment is stable and will not be redeployed during the engagement window
• Provide API documentation, Swagger/OpenAPI specs, and any relevant architecture diagrams
• Designate a technical point of contact who can resolve access issues quickly during the engagement
• Set up a secure communication channel (encrypted email or a shared Slack channel) for real-time questions

Legal and Administrative Setup

Penetration testing involves activities that would be illegal without proper authorization. Ensure the following administrative items are completed before testing begins:

• Execute a signed Statement of Work (SOW) that defines scope, timeline, and deliverables
• Sign a mutual NDA to protect both parties' confidential information
• Obtain written authorization from any third-party hosting providers if required by their terms of service (AWS, GCP, and Azure no longer require pre-authorization for most testing activities, but verify your specific provider's policy)
• Confirm your cyber insurance coverage in case an issue arises during testing
• Establish rules of engagement including testing hours, emergency contact procedures, and escalation paths

Phase 2: Authentication and Session Testing

Authentication is the front door to your application. If it is compromised, every other security control becomes irrelevant. This section covers the key authentication and session management tests that every web application penetration test should include.

Authentication Mechanism Testing

• Credential brute force: Test whether the application enforces account lockout or progressive delays after repeated failed login attempts. Many startups implement rate limiting at the application layer but forget to protect their API authentication endpoints.
• Password policy enforcement: Verify that the application enforces minimum password complexity requirements and rejects commonly breached passwords. Test whether password requirements are enforced consistently across registration, password change, and password reset flows.
• Multi-factor authentication bypass: If MFA is implemented, test for bypass techniques including direct API access that skips the MFA step, session fixation after the first authentication factor, and MFA fatigue attack scenarios.
• Password reset flow: Test the complete password reset process for weaknesses including predictable reset tokens, token reuse, lack of token expiration, user enumeration through error messages, and host header injection in reset emails.
• OAuth/SSO implementation: If the application uses OAuth or SAML for authentication, test for state parameter validation, redirect URI validation, token leakage, and IdP confusion attacks.

Session Management Testing

• Session token entropy: Verify that session tokens are generated with sufficient randomness and cannot be predicted or brute-forced.
• Session fixation: Test whether the application issues a new session token after successful authentication. If the pre-authentication token persists, an attacker can set a known session token and wait for the victim to authenticate.
• Session invalidation: Verify that sessions are properly invalidated on logout, password change, and after the configured timeout period. Test whether the server-side session is destroyed, not just the client-side cookie.
• Cookie security attributes: Verify that session cookies include Secure, HttpOnly, and SameSite attributes. Check that cookie scope is appropriately restricted to prevent leakage to subdomains or parent domains.
• Concurrent session controls: Test whether the application allows unlimited concurrent sessions and whether the user can view and revoke active sessions.

Phase 3: Authorization Testing

Authorization vulnerabilities are consistently among the most impactful findings in web application penetration tests. They are also among the most commonly missed by automated scanners, which is why manual testing is essential. In our experience testing Bay Area startups, broken access control issues appear in roughly 70% of first-time assessments.

Horizontal Privilege Escalation

Horizontal privilege escalation occurs when a user can access resources belonging to another user with the same privilege level. This is the most common authorization vulnerability in modern web applications, particularly those with RESTful API architectures.

• Test every endpoint that accepts a resource identifier (user ID, account ID, document ID) by substituting identifiers belonging to other test accounts
• Check for Insecure Direct Object References (IDOR) across all CRUD operations, not just read operations. An application might correctly restrict viewing another user's profile but allow editing it
• Test indirect references such as sequential order numbers, invoice IDs, or file paths that might be guessable
• Examine GraphQL queries for authorization enforcement, as GraphQL's flexible query structure often exposes data that the REST API properly restricts

Vertical Privilege Escalation

Vertical privilege escalation occurs when a lower-privileged user can perform actions reserved for higher-privileged roles. Test these scenarios systematically:

• Capture requests made by admin accounts and replay them using regular user session tokens
• Test administrative API endpoints with non-administrative credentials
• Look for hidden admin functionality exposed through client-side code, JavaScript files, or API documentation
• Test role assignment functionality to determine whether a user can escalate their own role
• Examine multi-tenant boundaries to ensure users from one tenant cannot access another tenant's resources

Phase 4: Injection Testing

Injection vulnerabilities occur when untrusted data is sent to an interpreter as part of a command or query. Despite decades of awareness, injection flaws remain prevalent, especially in startup codebases where speed of development is prioritized over security rigor.

SQL Injection

Test every user-controllable input that interacts with a database, including form fields, URL parameters, HTTP headers, cookies, and JSON/XML request bodies. Testing should cover:

• Classic in-band SQL injection with both error-based and union-based techniques
• Blind SQL injection using boolean-based and time-based inference
• Second-order SQL injection where the payload is stored and executed later in a different context
• ORM-specific injection patterns for frameworks like Sequelize, SQLAlchemy, ActiveRecord, and Prisma
• NoSQL injection for applications using MongoDB, DynamoDB, or similar databases

Cross-Site Scripting (XSS)

XSS testing should cover all three variants across every input and output context in the application:

• Reflected XSS: Test URL parameters, form inputs, and HTTP headers for immediate reflection in the response without proper encoding
• Stored XSS: Test every field that stores user input and displays it to other users, including profile fields, comments, file names, and metadata
• DOM-based XSS: Analyze client-side JavaScript for dangerous sinks (innerHTML, document.write, eval) that process user-controllable sources (location.hash, postMessage data, URL parameters)

Pay special attention to context-specific encoding requirements. Input that is safely encoded for HTML body context may still be exploitable in JavaScript string context, HTML attribute context, or URL context.

Other Injection Vectors

• Server-Side Request Forgery (SSRF): Test any functionality that accepts URLs or makes server-side HTTP requests. Webhook URLs, URL preview features, PDF generators, and file import functions are common SSRF targets.
• Server-Side Template Injection (SSTI): If the application uses server-side templates, test for template injection in any user-controllable input that is rendered through the template engine.
• Command Injection: Test any functionality that might invoke operating system commands, particularly file processing, image manipulation, and PDF generation features.
• LDAP/XML/XPath Injection: Test applications that interact with LDAP directories, parse XML input, or use XPath queries for injection vulnerabilities specific to these interpreters.

Phase 5: File Upload and Processing Testing

File upload functionality is one of the highest-risk features in any web application. A single file upload vulnerability can lead to remote code execution, complete server compromise, and lateral movement into your cloud infrastructure.

• File type validation: Test whether the application validates file types using content-type headers only (easily spoofed), file extensions only (easily bypassed), or actual file content analysis (more robust). Attempt to upload executable files with modified extensions and content types.
• File size limits: Verify that file size limits are enforced on the server side, not just the client side. Upload extremely large files to test for denial of service conditions.
• File storage location: Determine whether uploaded files are stored within the web root (potentially accessible and executable) or in a separate storage service like S3.
• File name handling: Test for path traversal in file names (e.g., ../../etc/passwd), special characters that might cause issues in the file system, and excessively long file names.
• Image processing vulnerabilities: If the application processes uploaded images (resizing, thumbnail generation), test for image processing library vulnerabilities such as ImageTragick, libpng exploits, and SVG-based SSRF.
• Malware scanning: Verify whether uploaded files are scanned for malware before being stored and served to other users.

Phase 6: API Endpoint Security

Modern web applications are almost universally built on APIs. The API layer is often the most exposed and least tested component, particularly for startups that ship API features rapidly to support mobile clients, partner integrations, and frontend frameworks.

API Discovery and Documentation

• Review provided API documentation (Swagger/OpenAPI specs) for completeness and accuracy
• Spider the application to discover undocumented API endpoints
• Analyze JavaScript source code for API endpoint references
• Check for exposed API documentation endpoints (/swagger, /api-docs, /graphql/playground)
• Look for version-specific endpoints (/api/v1/, /api/v2/) where older versions may lack security controls

API-Specific Testing

• Mass assignment: Test whether API endpoints accept and process parameters beyond those documented, allowing attackers to modify fields like role, isAdmin, or price that should be server-controlled.
• Rate limiting: Verify that API endpoints enforce appropriate rate limits. Unthrottled endpoints can enable brute force attacks, data scraping, and denial of service.
• Pagination and data exposure: Test whether list endpoints expose excessive data through pagination manipulation, requesting large page sizes, or accessing all records without filtering.
• HTTP method testing: Test each endpoint with HTTP methods beyond those documented. An endpoint that properly restricts GET requests may accept PUT or DELETE without authorization.
• Content-type manipulation: Test whether endpoints accept content types beyond those documented. An endpoint designed for JSON might also accept XML, potentially enabling XXE attacks.

Phase 7: Client-Side Security

Client-side security testing examines the security controls implemented in the browser and how the application handles client-side data and interactions.

Security Headers

Verify the presence and correct configuration of the following security headers. Missing security headers are among the most common low-severity findings in penetration test reports, and they are also among the easiest to fix.

• Content-Security-Policy (CSP): Check for a CSP that effectively prevents inline script execution and restricts resource loading to trusted sources. A CSP with unsafe-inline or unsafe-eval provides minimal protection against XSS.
• Strict-Transport-Security: Verify HSTS is configured with an appropriate max-age, includeSubDomains, and ideally preload directives.
• X-Content-Type-Options: Should be set to nosniff to prevent MIME type sniffing.
• X-Frame-Options: Should be set to DENY or SAMEORIGIN to prevent clickjacking. Alternatively, verify that CSP frame-ancestors directive is configured.
• Referrer-Policy: Should be configured to prevent leaking sensitive URL parameters to third-party sites.
• Permissions-Policy: Should restrict access to browser features (camera, microphone, geolocation) that the application does not need.

Sensitive Data in Client-Side Storage

• Examine localStorage, sessionStorage, and IndexedDB for sensitive data such as authentication tokens, PII, or API keys
• Review JavaScript source code for hardcoded credentials, API keys, or secrets
• Check for sensitive data in URL parameters that might be logged or cached
• Verify that sensitive form fields have autocomplete disabled where appropriate

Third-Party Dependencies

Modern web applications include dozens or hundreds of third-party JavaScript libraries. Each one is a potential supply chain risk. During the assessment:

• Inventory all third-party JavaScript loaded by the application
• Check for known vulnerabilities in included library versions
• Verify that Subresource Integrity (SRI) hashes are used for CDN-hosted scripts
• Assess the risk of supply chain attacks through compromised third-party scripts

Phase 8: Reporting and Remediation

A penetration test is only as valuable as the report it produces and the remediation that follows. For startups, the report serves multiple audiences: engineering teams need technical details to fix issues, management needs risk context to prioritize resources, and auditors need evidence that testing was performed rigorously.

What a Good Pentest Report Should Include

• Executive summary: A non-technical overview of the assessment scope, methodology, key findings, and overall risk posture. This is what your CEO, board, and investors will read.
• Methodology description: Documentation of the testing approach, tools used, and frameworks referenced (OWASP, PTES, etc.). This satisfies auditor requirements for evidence of systematic testing.
• Detailed findings: Each vulnerability should include a clear description, risk rating (using CVSS or a similar framework), step-by-step reproduction instructions, evidence (screenshots, request/response pairs), and specific remediation guidance.
• Positive findings: Document security controls that were tested and found to be effective. This is valuable for compliance documentation and gives the engineering team credit for what they have done well.
• Prioritized remediation roadmap: A practical plan that organizes findings by severity and effort, helping the engineering team tackle the most critical issues first.

Remediation Best Practices for Startups

Startups operate under resource constraints that make "fix everything immediately" impractical. A pragmatic approach to remediation recognizes this reality while ensuring that critical risks are addressed promptly.

• Critical and High findings: Address within 30 days. These represent exploitable vulnerabilities that could lead to significant data breaches or system compromise. Block other feature work if necessary.
• Medium findings: Address within 90 days. These represent real risks but require more specific conditions to exploit. Include them in upcoming sprint planning.
• Low and Informational findings: Address within 180 days or as part of regular maintenance cycles. These are defense-in-depth improvements rather than critical fixes.

After remediation, schedule a retest to verify that fixes are effective and have not introduced new issues. Many penetration testing firms, including CyberGuards, include a retest as part of the initial engagement. Taking advantage of the retest demonstrates to auditors and customers that your organization does not just identify vulnerabilities but actually resolves them.

Building a Continuous Testing Program

A single penetration test provides a snapshot of your security posture at a specific point in time. For startups that deploy code daily or weekly, that snapshot becomes outdated quickly. Building a continuous testing program ensures that security keeps pace with development velocity.

Quarterly assessments are the minimum cadence we recommend for startups with active development. This aligns with SOC 2 expectations and ensures that significant new features receive security review. Many of our San Francisco-based startup clients opt for continuous engagement models where our team tests new features as they are deployed, providing near-real-time security feedback.

Bug bounty programs complement periodic penetration tests by providing ongoing coverage from a diverse pool of researchers. However, a bug bounty is not a substitute for a structured penetration test. Bug bounty hunters optimize for quantity and reward, which means they tend to focus on easy-to-find issues and may skip complex business logic testing.

Automated security testing in CI/CD provides continuous baseline coverage. Tools like SAST, DAST, SCA, and secret scanning should be integrated into your development pipeline. These automated tools catch common issues early, allowing penetration testers to focus on complex vulnerabilities that require human creativity and business context.

"The best time to start a security testing program was when you wrote your first line of code. The second best time is now. Every day without testing is a day of accumulated risk that will be more expensive to address later."

Key Takeaways

• Preparation is half the battle. Clear scope definition, proper test accounts, and environment readiness determine the quality of your penetration test.
• Authorization testing (IDOR/BOLA) consistently produces the highest-impact findings in startup applications and cannot be effectively automated.
• Every injection vector deserves testing, but prioritize based on your application's specific technology stack and data sensitivity.
• File upload functionality and API endpoints are high-risk areas that warrant focused manual testing.
• The pentest report should serve multiple audiences and, for SOC 2 purposes, map findings to Trust Service Criteria.
• Build toward continuous testing rather than relying on annual point-in-time assessments.