Launching a web application without proper security testing is like deploying a building without a fire inspection. Everything might look fine on the surface, but hidden vulnerabilities can lead to catastrophic failures. This web application security testing checklist distills the most critical checks into 15 actionable items that every development team should complete before going live. Whether you are a startup racing toward your first release or an established company shipping a major feature update, these checks form the minimum viable security posture for any production web application.
This checklist is designed to complement, not replace, a professional penetration test. Think of it as the security equivalent of a pre-flight checklist: it catches the most common and dangerous issues before they reach your users.
1. Authentication Mechanism Review
Authentication is the front door to your application, and it must be thoroughly tested before launch. Start by verifying that passwords are hashed using a modern algorithm such as bcrypt, scrypt, or Argon2id with appropriate cost factors. Never store passwords in plaintext or with reversible encryption.
Test for common authentication weaknesses: Are there account lockout or rate-limiting mechanisms after failed login attempts? Can users set extremely weak passwords? Is multi-factor authentication available and enforced for administrative accounts? Does the password reset flow leak information about which email addresses are registered? Are authentication tokens (JWTs, session cookies) generated with sufficient entropy and signed with strong keys?
Verify that authentication state cannot be bypassed by directly accessing protected URLs. Every protected endpoint should independently verify the user's authentication status on the server side, not rely on client-side routing or hidden navigation elements.
2. Session Management Testing
Session management vulnerabilities can allow attackers to hijack authenticated user sessions. Verify that session IDs are regenerated after successful login to prevent session fixation attacks. Ensure that session cookies are set with the Secure, HttpOnly, and SameSite attributes. The Secure flag prevents transmission over unencrypted connections, HttpOnly prevents JavaScript access, and SameSite mitigates cross-site request forgery.
Test session timeout behavior. Sessions should expire after a reasonable period of inactivity, typically 15 to 30 minutes for sensitive applications. When a user logs out, verify that the session is completely invalidated on the server side, not just cleared from the browser. Also test for concurrent session limits: can an attacker use a stolen session token simultaneously with the legitimate user without any detection or restriction?
3. Input Validation and Sanitization
Every input your application accepts is a potential attack vector. Test all input fields, URL parameters, headers, cookies, and file uploads for proper validation. Implement a whitelist approach wherever possible, defining exactly what valid input looks like rather than trying to blacklist malicious patterns.
Verify that input validation happens on the server side. Client-side validation improves user experience but provides zero security, since any attacker can bypass it by sending requests directly to your API. Check that validation is applied consistently across all entry points, including API endpoints that might be overlooked because they are not exposed through the user interface.
Pay special attention to inputs that are used in database queries, shell commands, file system operations, or rendered in HTML output. These are the most dangerous contexts for unvalidated input, and they map directly to the injection and XSS checks that follow.
4. Cross-Site Request Forgery (CSRF) Protection
CSRF attacks trick authenticated users into performing unintended actions by exploiting the browser's automatic inclusion of cookies with same-origin requests. Verify that all state-changing operations (form submissions, API calls that modify data) are protected with anti-CSRF tokens.
Modern frameworks typically provide CSRF protection out of the box, but it is easy to disable accidentally or forget to apply to new endpoints. Test by intercepting a legitimate request, removing or modifying the CSRF token, and confirming that the server rejects the tampered request. For API-first applications using bearer tokens instead of cookies, CSRF is less of a concern, but verify that cookie-based authentication is not also accepted.
Additionally, verify that the SameSite cookie attribute is set to Lax or Strict on session cookies, providing a defense-in-depth layer against CSRF even if token-based protection has gaps.
5. Cross-Site Scripting (XSS) Prevention
XSS remains one of the most prevalent web application vulnerabilities. Test for all three types: reflected XSS (malicious script in URL parameters reflected in the page), stored XSS (malicious script persisted in the database and served to other users), and DOM-based XSS (client-side JavaScript processing untrusted data into dangerous sinks).
Verify that all user-supplied data is properly encoded when rendered in HTML context. Use context-appropriate encoding: HTML entity encoding for HTML body content, JavaScript encoding for script contexts, URL encoding for URL parameters, and CSS encoding for style contexts. Modern template engines like React's JSX, Angular's template syntax, and Jinja2 with autoescape handle this automatically, but raw HTML rendering, dangerouslySetInnerHTML, and similar escape hatches bypass these protections.
Test with a variety of payloads across different contexts. Simple alert-box payloads may be caught by basic filters while more sophisticated payloads using event handlers, SVG elements, or encoding tricks bypass them. A Content Security Policy (CSP) header provides an additional layer of defense.
6. SQL Injection Testing
Despite decades of awareness, SQL injection continues to appear in production applications, particularly in custom query builders, reporting features, search functionality, and anywhere raw SQL is used alongside an ORM. Test all inputs that interact with the database, including search fields, filter parameters, sorting parameters, and API query parameters.
Verify that the application uses parameterized queries or prepared statements exclusively. Even a single instance of string concatenation in a database query creates a potential SQL injection vulnerability. Test with standard payloads like single quotes, UNION SELECT statements, and time-based blind injection techniques. If your application uses a NoSQL database, test for NoSQL injection as well, particularly in MongoDB where JSON operator injection is common.
For a deeper dive into injection testing methodology, see our web application penetration testing guide.
7. File Upload Security
If your application accepts file uploads, this feature requires careful security testing. Attackers commonly attempt to upload web shells, malware, or files that exploit processing libraries. Verify the following controls are in place:
Validate file types using both the Content-Type header and actual file content (magic bytes), not just the file extension. Restrict allowed file types to the minimum necessary. Store uploaded files outside the web root or in a separate storage service like S3, never in a directory that can execute scripts. Rename uploaded files to random names to prevent path traversal attacks. Set a maximum file size limit. Scan uploaded files with antivirus or malware detection. If images are processed, use a library that is up to date and not vulnerable to image processing exploits.
8. API Security Validation
Modern web applications are API-driven, and API endpoints often have weaker security controls than their web interface counterparts. Test every API endpoint for proper authentication, authorization, input validation, and rate limiting. Pay particular attention to:
Endpoints that expose data through different levels of detail (list views vs. detail views may leak additional fields). Batch operations that bypass per-record authorization checks. GraphQL endpoints where overly permissive schemas allow querying sensitive fields or performing expensive nested queries. Ensure that API documentation or Swagger/OpenAPI definitions are not publicly accessible in production unless intentionally so. Verify that API responses do not include sensitive fields that the frontend does not display but an attacker could read.
9. HTTPS and TLS Configuration
All production traffic must be encrypted with TLS. Verify that HTTPS is enforced on every page and API endpoint, not just login and payment pages. Test the following:
HTTP requests are redirected to HTTPS with a 301 redirect. The Strict-Transport-Security (HSTS) header is set with a sufficiently long max-age (at least one year) and includes subdomains. TLS 1.0 and 1.1 are disabled, leaving only TLS 1.2 and 1.3. Weak cipher suites are disabled. The SSL certificate is valid, properly chained, and not near expiration. Mixed content is eliminated: no HTTP resources loaded on HTTPS pages. Use a tool like SSL Labs to verify your configuration scores an A or A+.
10. Security Headers Implementation
HTTP security headers provide critical defense-in-depth protections that take minutes to implement but significantly raise the bar for attackers. Verify that the following headers are present on all responses:
Content-Security-Policy (CSP): Restricts which resources the browser can load, providing strong XSS mitigation. Start with a restrictive policy and loosen only as needed. X-Content-Type-Options: nosniff: Prevents MIME type sniffing. X-Frame-Options: DENY or SAMEORIGIN: Prevents clickjacking. Referrer-Policy: Controls how much referrer information is sent. Permissions-Policy: Restricts browser features like camera, microphone, and geolocation access. Test these headers across all response types, not just HTML pages.
11. Error Handling and Information Disclosure
Improper error handling can leak sensitive information that helps attackers map your application's internals. Verify that production error pages do not display stack traces, database error messages, file paths, framework versions, or server configuration details.
Test with intentionally malformed requests, invalid URLs, missing parameters, and oversized inputs. Each error scenario should return a generic, user-friendly error message while logging the detailed error information server-side. Ensure that custom error pages are configured for all common HTTP error codes (400, 401, 403, 404, 500). Check that API error responses do not include internal implementation details.
12. Logging and Monitoring Setup
Before launching, verify that your application logs the events necessary to detect and investigate security incidents. At minimum, log all authentication attempts (successful and failed), authorization failures, input validation failures, administrative actions, and changes to security-relevant configurations.
Ensure that logs do not contain sensitive data such as passwords, credit card numbers, or personally identifiable information. Verify that logs are shipped to a centralized logging platform and that basic alerting is configured for suspicious patterns such as repeated failed login attempts, access to admin endpoints from unexpected IPs, or spikes in error rates. You should be able to answer the question "who did what, when, and from where" for any security-relevant action.
13. Access Control Testing
Beyond authentication, verify that authorization controls are correctly implemented at every level. Test horizontal privilege escalation by accessing another user's resources using their IDs. Test vertical privilege escalation by attempting administrative actions with a regular user account. Test with multiple user roles to verify that each role can only access the functionality and data it should.
Common access control failures include IDOR vulnerabilities where changing an ID parameter in a URL or API request reveals another user's data, missing authorization checks on administrative API endpoints, and inconsistent enforcement between the web interface and API. Access control testing is difficult to automate effectively and is one of the primary reasons why professional penetration testing adds value beyond automated scanning.
14. Dependency Scanning and Updates
Your application's security is only as strong as its weakest dependency. Before launch, run a complete dependency scan using tools like npm audit, pip-audit, bundler-audit, or a commercial SCA tool like Snyk or Dependabot. Identify and remediate all high and critical severity vulnerabilities.
Review your dependency tree for abandoned or unmaintained packages that may not receive security updates. Check that your lock file is committed to version control and that builds are reproducible. Establish a process for ongoing dependency monitoring and updates post-launch. For more on building security into your development pipeline, see our guide on securing your CI/CD pipeline.
15. Secrets Management Audit
The final check before launch is a thorough audit of secrets management. Scan your entire codebase, including git history, for hard-coded credentials, API keys, database connection strings, encryption keys, and other secrets. Use tools like truffleHog, git-secrets, or Gitleaks to automate this scan.
Verify that all secrets in production are stored in environment variables or a dedicated secrets management service, never in configuration files committed to version control. Ensure that .env files are in .gitignore. Check that API keys have appropriate scope restrictions and are rotatable. Verify that database credentials use the principle of least privilege. If any secrets have been previously committed to git history, rotate them immediately, because removing them from future commits does not remove them from history.
Putting the Checklist Into Practice
This web application security testing checklist is designed to be practical and actionable. We recommend assigning each check to a specific team member with a completion deadline aligned to your launch date. Many of these checks can be partially automated and integrated into your CI/CD pipeline for ongoing enforcement.
However, a checklist is a starting point, not a finish line. Automated tools and internal checks catch common issues, but they miss business logic flaws, complex access control bypasses, and chained vulnerabilities that require human creativity to discover. We strongly recommend complementing this checklist with a professional penetration test, particularly for applications that handle sensitive data or have regulatory requirements.
At Lorikeet Security, we help startups and mid-market companies across all service areas validate their security posture before and after launch. Our testing methodology goes beyond checklist items to provide thorough, expert-driven assessment of your application's security. Engagements start at $2,500.
Go Beyond the Checklist with Expert Penetration Testing
Our security engineers test for complex vulnerabilities that checklists and automated scanners miss. Get a thorough assessment of your web application before launch day.
