Web App Security Audit Checklist: 25 Checks Before Launch
Complete security audit checklist for web applications. 25 critical checks covering secrets, auth, injection, headers, database, and deployment security.
By Gabriel CA · Kraftwire Software
· 9 min readKey Takeaway
A security audit is not a one-time event. It is a repeatable process that helps you find and fix vulnerabilities before attackers do. This checklist gives you a structured approach to auditing any web application.
Why You Need a Security Audit Checklist
Most security breaches exploit known vulnerabilities. Outdated dependencies, exposed API keys, missing access controls. These are not sophisticated zero-day attacks. They are basic issues that a structured audit would catch.
The problem is that security audits feel overwhelming. Where do you start? What do you check? How do you know when you are done? A checklist solves that by breaking the audit into manageable categories.
Authentication Audit
Authentication is the front door of your application. If it is weak, nothing else matters.
What to Check
**Password Policy**: Are you enforcing minimum length (at least 8 characters)? Do you check passwords against known breach databases? Avoid overly complex rules that push users toward predictable patterns like "Password1!" which technically meets most requirements but is easy to guess.
**Session Management**: How long do sessions last? Are session tokens rotated after login? Can a user have multiple active sessions? If someone compromises a session token, how quickly can you invalidate it?
**Multi-Factor Authentication**: Is MFA available for all users? Is it required for admin accounts? What methods do you support (TOTP, SMS, passkeys)?
**Brute Force Protection**: Do you rate limit login attempts? After how many failures do you lock the account or add a delay? Are you tracking failed attempts per IP and per account?
// Example: Rate limiting login attempts
const MAX_ATTEMPTS = 5;
const LOCKOUT_MINUTES = 15;
async function checkLoginAttempts(email: string, ip: string) {
const recentAttempts = await db.loginAttempts.count({
where: {
OR: [{ email }, { ip }],
createdAt: { gte: new Date(Date.now() - LOCKOUT_MINUTES * 60000) },
success: false,
},
});
return recentAttempts < MAX_ATTEMPTS;
}
Authorization Audit
Authentication verifies who someone is. Authorization controls what they can do. Many apps get authentication right but leave authorization gaps.
What to Check
**Role-Based Access**: Are roles stored securely (in the database, not in JWT claims that the client can modify)? Can users escalate their own privileges? Are admin endpoints protected on the server side?
**Row-Level Security**: Can users access other users data by changing an ID in the URL or API request? This is called an Insecure Direct Object Reference (IDOR), and it is one of the most common web vulnerabilities.
**API Endpoint Protection**: Is every API endpoint that modifies data protected by an authorization check? Do not assume that hiding a button in the UI prevents access. Anyone can call your API directly.
Data Protection Audit
Data breaches are expensive, both financially and in terms of user trust. Protecting data at rest and in transit is non-negotiable.
What to Check
**Encryption in Transit**: Is HTTPS enforced everywhere? Are you using HSTS headers? Check that your TLS configuration uses modern cipher suites and does not support deprecated protocols like TLS 1.0 or 1.1.
**Encryption at Rest**: Are sensitive fields (like personal data or financial information) encrypted in the database? Who has access to the encryption keys?
**Data Minimization**: Are you collecting only the data you need? Storing unnecessary personal information increases your liability and the impact of a potential breach.
**Backup Security**: Are database backups encrypted? Who has access to them? How long are they retained?
API Security Audit
APIs are the backbone of modern applications, and they are also the most common attack surface.
What to Check
**Input Validation**: Is every API endpoint validating its inputs? Are you checking types, lengths, ranges, and formats? Use a schema validation library like Zod to define and enforce input shapes.
**Rate Limiting**: Can an attacker flood your API with requests? Implement rate limiting on all public endpoints, with stricter limits on authentication and payment endpoints.
**Error Responses**: Do your API errors leak implementation details? Stack traces, database column names, and file paths help attackers understand your system. Return generic error messages to clients.
// Bad: Leaks internal details
catch (error) {
return { error: error.message, table: "users", column: "email" };
}
// Good: Generic client response
catch (error) {
logger.error("API error", { error, endpoint: "/api/users" });
return { error: "Request failed. Please try again." };
}
Infrastructure Audit
Your application code might be secure, but infrastructure misconfigurations can expose everything.
What to Check
**Environment Variables**: Are all secrets stored in environment variables, not in code? Are different environments (development, staging, production) using different credentials?
**CORS Configuration**: Is your CORS policy specific to your domains, or is it using a wildcard (*) that allows any origin?
**Security Headers**: Are you setting X-Frame-Options, X-Content-Type-Options, Content-Security-Policy, and Strict-Transport-Security headers?
**DNS and Domain Security**: Is DNSSEC enabled? Are SPF, DKIM, and DMARC records configured for your email domain?
Dependency Audit
Third-party packages are a major source of vulnerabilities. The average web application has hundreds of dependencies, and any one of them could introduce a security issue.
What to Check
Run `npm audit` or `yarn audit` and fix high and critical findings
Check for outdated packages that are no longer maintained
Review the permissions and scope of each dependency
Look for packages with known supply chain attacks
Logging and Monitoring Audit
If you cannot detect an attack, you cannot respond to it. Logging and monitoring are your early warning system.
What to Check
Are authentication events (login, logout, failed attempts) logged?
Are authorization failures logged?
Are logs stored securely and retained for an appropriate period?
Do you have alerts for unusual activity (spike in failed logins, unexpected data access patterns)?
Can you correlate events across your application to reconstruct an attack timeline?
Your Complete Security Audit Checklist
Authentication
[ ] Password policy enforces minimum length and breach checks
[ ] Sessions expire and tokens rotate after login
[ ] MFA is available and required for admin accounts
[ ] Brute force protection with rate limiting and lockouts
Authorization
[ ] Roles stored securely in the database
[ ] IDOR protection on all data access endpoints
[ ] Server-side authorization on every API endpoint
Data Protection
[ ] HTTPS enforced with HSTS headers
[ ] Sensitive data encrypted at rest
[ ] Data minimization practiced
[ ] Backups encrypted and access-controlled
API Security
[ ] Input validation on all endpoints
[ ] Rate limiting on public and sensitive endpoints
[ ] Generic error messages returned to clients
Infrastructure
[ ] Secrets in environment variables, not code
[ ] CORS restricted to specific domains
[ ] Security headers configured
[ ] DNS security records in place
Dependencies
[ ] npm audit shows no high or critical vulnerabilities
[ ] No unmaintained packages in use
Monitoring
[ ] Authentication events logged
[ ] Authorization failures logged
[ ] Alerts configured for unusual activity
Make It Repeatable
The best security audit is one you run regularly. Set a schedule, whether that is monthly, quarterly, or before every major release, and work through this checklist each time. Automated scanning tools like SimplyScan can handle the routine checks, freeing you to focus on business logic and architecture review.