Code Audit Checklist (Free Template)

What this template is

This is the working checklist a reviewer can run against any production codebase in half a day to two days, depending on size. It is written for engineering leads, founders with technical background, and senior developers who inherited a codebase and need to know where it stands. It is the same lens we apply when we audit code for teams, condensed into a format you can copy into an issue tracker and start checking boxes.

How to use it: work top to bottom. The sections are ordered by risk, not by effort. Copy the markdown source directly, paste it into a GitHub issue, Notion page, or Linear project, and assign one owner per section. Check a box only when you have evidence (a command output, a code reference, a test), not a feeling. If you want a deeper explanation of any section, the free code audit checklist guide walks through the reasoning behind each item.

1. Secrets and credentials

• No secrets in the repo or its history: run gitleaks detect --source . -v and get a clean result
• Frontend build output contains no server-side keys: grep the built bundle for sk_live, AKIA, service_role, and -----BEGIN
• .env files and key material are in .gitignore, and were never committed before the ignore rule existed
• Every secret found in history has been rotated, not just deleted (see the secrets scanning tutorial for the full procedure)
• Production credentials differ from staging and development credentials
• Secrets are injected at deploy time (environment variables or a secrets manager), never hardcoded

2. Authentication and authorization

• Every privileged endpoint checks the caller’s role server-side, not just in the UI
• Object-level authorization holds: log in as user A, request user B’s resource by ID with curl, confirm a 403 or 404
• Sessions expire, logout invalidates the token, and password reset tokens are single-use with a short TTL
• Passwords are hashed with bcrypt, scrypt, or argon2 (never MD5, SHA1, or plaintext)
• Rate limiting exists on login, signup, and password reset endpoints
• Admin routes are not discoverable by predictable URLs alone

3. Input validation and injection

• All database access uses parameterized queries or an ORM; grep for string concatenation into SQL
• User-supplied HTML is sanitized or escaped before rendering; search for dangerouslySetInnerHTML, innerHTML, and template | safe filters
• File uploads validate type and size server-side and are stored outside the web root
• Redirect targets, webhook URLs, and any user-supplied URL are validated against an allowlist (SSRF)
• Deserialization of user input uses safe parsers, never eval, pickle.loads, or yaml.load without a safe loader

4. Dependencies

• npm audit / pip-audit / bundler-audit runs clean of critical and high findings, or each one has a written exception
• A lockfile exists, is committed, and CI installs from it (npm ci, not npm install)
• No dependency is more than one major version behind on a security-supported release line
• Unused dependencies are removed: run depcheck or equivalent
• Automated update PRs (Dependabot or Renovate) are enabled; the dependency audit tutorial covers setup

5. Error handling and logging

• Production error responses never leak stack traces, SQL, or file paths to the client
• Every caught exception is either handled or logged; no empty catch {} blocks
• Logs exclude passwords, tokens, and full card numbers
• An error tracker (Sentry or similar) is wired up and alerts reach a human
• Failed background jobs retry with backoff and dead-letter somewhere visible

6. Tests and CI

• The test suite runs in CI on every pull request and blocks merge on failure
• The critical money paths (signup, checkout, permissions) each have at least one automated test
• Tests use fixtures or factories, not a shared mutable staging database
• Coverage is measured; the trend matters more than the absolute number
• A new engineer can run the suite locally with one documented command

7. Performance and data

• The top five endpoints have been profiled; no N+1 query patterns in list views
• Database columns used in WHERE clauses and JOINs are indexed
• Pagination exists on every list endpoint; nothing returns unbounded result sets
• Backups run automatically and a restore has actually been tested, not assumed
• Slow query logging is enabled in production

How to act on the results

Do not fix in checklist order once you have results. Sort every failed item by severity times exposure: a leaked live API key outranks a missing index, and a broken authorization check outranks both a slow query and a flaky test. Fix critical security items within days, high items within the sprint, and batch the rest into normal maintenance. Our guide on prioritizing fixes after an audit gives a full triage framework with time horizons.

Keep the checklist alive: rerun the secrets and dependency sections monthly, and the full list quarterly or before any major release. A checklist run once is a snapshot; run on a schedule, it is a control.

Want us to run it for you (free)

This checklist finds the common failures, but a checklist cannot read your architecture, spot the subtle authorization gap in your specific permission model, or tell you which of forty findings actually threatens your business. A Webisoft engineer can. Submit your repository and we will apply this exact lens, manually, and send you a prioritized written report at no cost: get a free code audit.