Small teams rarely have a dedicated security engineer. They don't need one to avoid the most common problems. Most incidents in everyday web software come from a short list of causes: an exposed setting, an outdated library, a missing access check, a secret committed to a repository. Each has a routine fix.

This checklist is what we apply on our own projects. It draws on two public references worth bookmarking: the OWASP Top 10 for web application risks, and NIST's Secure Software Development Framework (SP 800-218) for development practices.

1. Protect the code and the pipeline

  • Require pull requests and at least one review before anything merges to the main branch.
  • Turn on branch protection so no one can push directly to production branches.
  • Use multi-factor authentication on every developer account and on your hosting and DNS providers.
  • Keep deployment manual or gated for production, with a clear record of who deployed what.

2. Keep secrets out of the repository

  • Store API keys, passwords and tokens in your platform's secret store or environment variables, never in code.
  • Add secret scanning to your repository, and treat any committed secret as compromised: rotate it, then remove it.
  • Keep server-side configuration outside the public web root.

3. Manage dependencies

  • Enable automated dependency updates (for example Dependabot) and review them weekly.
  • Run a dependency audit in continuous integration and fail the build on high-severity issues.
  • Remove packages you no longer use. Every dependency is code you are trusting.

4. Scan automatically

  • Add static analysis (SAST) to every pull request.
  • Run a dynamic scan (DAST), such as OWASP ZAP's baseline scan, against a staging environment before releases.
  • Scan container images if you ship containers.
  • Make serious findings block the release instead of producing a report nobody reads.

5. Get the basics of the application right

  • Validate input on the server, even if the browser already checked it.
  • Check authorization on every request, not only when pages load. Broken access control has been at the top of the OWASP Top 10.
  • Use parameterized queries or an ORM for database access.
  • Encode output to prevent cross-site scripting, and set a Content Security Policy.
  • Set security headers: HSTS, X-Content-Type-Options, X-Frame-Options or frame-ancestors, and Referrer-Policy.
  • Rate-limit logins, password resets and public forms.

6. Log what matters

  • Log authentication events, permission changes and administrative actions.
  • Keep logs somewhere the application itself can't erase.
  • Never log passwords, tokens or full payment details.

7. Plan for things going wrong

  • Write a one-page incident checklist: who to call, how to take the system offline, how to rotate credentials.
  • Test restoring from backup at least quarterly. A backup you have never restored is a hope, not a plan.

Make it routine

None of these steps is expensive on its own. The value comes from making them automatic, so security happens on every change rather than in a yearly review.

If you would like help building these checks into your pipeline, or a review of an application you already run, contact us.