A Practical Web Application Security Checklist for Small Teams

Most breaches at small companies aren’t sophisticated. They’re an old dependency, a leaked API key, or an admin page that never checked who was asking. The good news: the same is true in reverse — a modest, consistent set of practices blocks the large majority of real-world attacks. This is the checklist I use when reviewing client applications, written for teams without a dedicated security engineer.

1. Authentication: make account takeover hard

• Use a proven auth provider or framework library. Hand-rolled login systems are where audits find the worst bugs. Auth0, Clerk, Firebase Auth, or your framework’s battle-tested auth module all beat custom code.
• Hash passwords with a modern algorithm (bcrypt, scrypt, or Argon2). If your database stores anything you could read back as the original password, stop and fix that first.
• Offer multi-factor authentication, and require it for admin accounts.
• Rate-limit login and password-reset endpoints so attackers can’t guess credentials at scale.

2. Authorization: check permissions on every request

The most common serious flaw I find in reviews is missing object-level authorization: the app checks that you’re logged in, but not that invoice /api/invoices/4213 actually belongs to you. Attackers find these by simply changing the number.

• Enforce permissions on the server for every endpoint — never trust the UI to hide things.
• Check ownership of the specific resource, not just the user’s role.
• Deny by default: new endpoints should require an explicit permission rule to become accessible.

3. Dependencies: patch the code you didn’t write

Your application is mostly other people’s code. A known vulnerability in an old package version is the cheapest attack there is, because the exploit is public.

• Turn on automated dependency alerts (GitHub Dependabot or equivalent) and actually merge the updates.
• Run npm audit / pip-audit in CI so a critical vulnerability fails the build.
• Delete packages you no longer use — every dependency is attack surface.

4. Secrets: keep keys out of your codebase

• Never commit API keys, database passwords, or tokens to git. Once committed, treat them as leaked — rotate them, don’t just delete the file.
• Use environment variables or a secrets manager, and different credentials per environment.
• Scope keys narrowly: a key that can only read one bucket does far less damage when it leaks.

5. Input handling: the classics still work

SQL injection and cross-site scripting have been on the OWASP Top 10 for two decades because they keep working. The defenses are boring and effective:

• Use parameterized queries or an ORM — never build SQL by concatenating strings with user input.
• Let your frontend framework escape output by default; treat any HTML-injection helper (dangerouslySetInnerHTML and friends) as a code-review flag.
• Validate input on the server: type, length, format, and range.
• Set a Content-Security-Policy header — even a basic one limits the damage of an XSS slip.

6. Transport and headers

• HTTPS everywhere, with HTTP redirecting to HTTPS. Free certificates removed every excuse years ago.
• Add the standard security headers: Strict-Transport-Security, X-Content-Type-Options, X-Frame-Options (or CSP frame-ancestors).
• Mark session cookies Secure, HttpOnly, and SameSite.

7. Logging, backups, and the bad day

Prevention fails sometimes. What separates an incident from a catastrophe is whether you can see what happened and recover.

• Log authentication events, permission failures, and admin actions — with timestamps and user IDs, but never passwords or tokens.
• Back up automatically, and test a restore. An untested backup is a hope, not a plan.
• Write down, even on one page, who does what if you suspect a breach.

Security for a small team isn’t about buying tools. It’s about closing the handful of doors attackers actually try.

When to get an outside review

Self-checklists catch a lot, but they share your blind spots. Three moments when an independent security review earns its cost: before your first enterprise customer’s procurement process, after any major architecture change, and before you handle regulated data (payments, health, minors). A structured review maps your application against the OWASP Top 10 and hands your developers a prioritized fix list — which is exactly the work I do for clients.