Web Application Security Checklist for Startups

Veld Systems||5 min read

Security is not optional, even for early stage startups. A data breach costs the average small company $120K-$150K in direct costs plus the trust you can never buy back. Here is a prioritized checklist based on what actually gets exploited.

Priority 1: Authentication and Session Management

These are the vulnerabilities attackers look for first.

Use a proven auth library. Do not roll your own authentication. Use Supabase Auth, Auth0, Clerk, or NextAuth. Every custom auth system we have audited had at least one critical vulnerability. The libraries handle password hashing, session tokens, CSRF protection, and rate limiting correctly.

Enforce strong session management. HTTP only cookies for session tokens (not localStorage, it is vulnerable to XSS). Set Secure and SameSite flags. Expire sessions after reasonable timeouts. Invalidate sessions server side on logout.

Add multi factor authentication. At minimum for admin accounts. TOTP (Google Authenticator) is easy to implement and stops 99% of credential stuffing attacks.

Priority 2: Input Validation and Injection Prevention

Parameterize every database query. SQL injection is still the most common web vulnerability. Never concatenate user input into SQL strings. Use parameterized queries or an ORM. If you use Supabase, the client library handles this, but custom RPC calls and raw SQL need manual parameterization.

Sanitize output to prevent XSS. Any user generated content rendered in HTML must be escaped. React does this by default for JSX expressions, but dangerouslySetInnerHTML and href attributes are still attack vectors. Use DOMPurify for any rich text rendering.

Validate on the server. Client side validation is for UX, not security. Every input must be validated server side with strict schemas. Use Zod or Yup for TypeScript validation, define the schema once and validate at every API boundary.

Priority 3: HTTPS and Security Headers

HTTPS everywhere. No exceptions. Vercel and most modern hosts handle this automatically. If you manage your own infrastructure, use Let's Encrypt with auto renewal. Check your CI/CD pipeline includes SSL verification.

Security headers. Add these to your response headers: Strict-Transport-Security (HSTS), Content-Security-Policy (CSP), X-Content-Type-Options: nosniff, X-Frame-Options: DENY, and Referrer-Policy: strict-origin-when-cross-origin. In Next.js, configure these in next.config.js headers.

CORS configuration. Whitelist specific origins, never use Access-Control-Allow-Origin: *. Restrict methods and headers to what your frontend actually needs.

Priority 4: Dependency and Secret Management

Scan dependencies regularly. Run npm audit weekly. Use Dependabot or Renovate for automated dependency updates. A single vulnerable transitive dependency can compromise your entire application. Check OWASP's dependency check tools.

Never commit secrets. Use environment variables for API keys, database credentials, and tokens. Add .env to .gitignore. Use a secrets manager (Vercel environment variables, AWS Secrets Manager, or Doppler) for production. Rotate any key that has ever been committed to git, git history is forever.

Principle of least privilege. Database users should have only the permissions they need. API keys should be scoped to specific services. Admin endpoints should require additional authentication. This limits the blast radius when (not if) something gets compromised.

Priority 5: Rate Limiting and API Protection

Rate limit all endpoints. Especially authentication, password reset, and any endpoint that sends emails or SMS. Without rate limiting, attackers can brute force credentials or rack up your Twilio bill. Use Upstash Redis rate limiting or similar middleware.

Validate file uploads. Check file types server side (not just the extension, check magic bytes). Limit file sizes. Store uploads in a separate domain/bucket to prevent XSS via uploaded HTML. Never serve user uploads from your main domain.

Log security events. Failed login attempts, permission denials, and input validation failures. These logs are how you detect attacks in progress. Forward them to a monitoring service and set up alerts for anomalous patterns.

Incident Response Preparation

Security is not just prevention. You need a plan for when something goes wrong.

Have an incident response plan. Document: who to contact, how to assess severity, how to communicate with affected users, and how to preserve evidence. A 30-minute response time requires a plan that already exists, not one you create during the incident.

Database backups tested monthly. Backups that have never been restored are not backups. They are hopes. Run a monthly restore to a test environment. Verify data integrity. Document the restore procedure so any team member can execute it at 3am.

Breach notification requirements. Know your legal obligations. GDPR requires notification within 72 hours. US state laws vary. Have a template communication ready. The worst time to write a breach notification is during a breach.

Audit logging. Log who accessed what, when, and from where. Store logs separately from your application database. If your database is compromised, your audit trail should not be. Retain logs for at least 90 days.

The Quick Wins

If you do nothing else today: enable HTTPS, use a proven auth library, parameterize your database queries, and add npm audit to your CI pipeline. These four actions prevent 80% of common attacks and take less than a day to implement.

Beyond the quick wins, schedule a monthly security review. Rotate API keys quarterly. Review access logs for unusual patterns. Update dependencies when security patches are released, not when you get around to it. Run OWASP ZAP or Burp Suite against your staging environment quarterly to catch vulnerabilities before attackers do. Security is not a one time project. It is a continuous practice that compounds over time, and the cost of maintaining good habits is a fraction of the cost of recovering from a breach.

For Traderly, we implemented all of these from day one, handling payments and user data for 100K+ users demands it. The same principles apply whether you have 100 users or 100K.

Our DevOps practice includes security audits as part of every infrastructure setup. Good security is not a one time checklist, it is baked into your development and deployment workflow.

Want a security audit of your application? We will tell you what is actually at risk.

Ready to Build?

Let us talk about your project

We take on 3-4 projects at a time. Get an honest assessment within 24 hours.