Free template

Free code audit checklist, evidence or it did not happen

A checklist for auditing a codebase before launch, a raise or a handover. It starts with whether the build matches what was agreed, then covers access control, secrets, dependencies, input handling, payments and reliability. Every finding gets a severity, a location and evidence. Copy it or download it as Markdown.

Get the templateDo this with Atrix AI

Free · Markdown · no sign-up

When to use it

An audit answers two questions: did we build what we agreed, and is it safe to put in front of customers? Run it at the points where the answer matters most.

  • Before a public launch or a store submission

  • When a contractor, studio or coding agent hands work back

  • Before due diligence, or before taking over someone else's codebase

  • After a large change to authentication, payments or data access

The template

The complete template

Everything below is included when you copy or download it. Replace the [bracketed] blanks and delete the guidance lines as you go.

Code audit: [Project name]

Replace everything in [brackets]. Tick a line only when you have seen the evidence yourself. Anything that fails becomes a numbered finding in the log at the end, and the audit passes only when the log has no open critical or high findings and the product is live.

01Scope

Pin exactly what is being audited. An audit of "the app" at no particular commit cannot be repeated.

  • Repository: [URL]
  • Commit or tag: [SHA or release tag]
  • Agreed scope: [PRD version or baseline number audited against]
  • Environment: [Production URL, store build, or staging]
  • Auditor and date: [Name], [date]

02Requirements coverage

Does the build match what was agreed? Work through the requirements one by one against the frozen scope.

  • Every Must requirement has acceptance criteria
  • Every Must requirement has finished work pointing at it
  • Each acceptance check passes on the running product
  • Requirements changed after sign-off are flagged, with old and new wording
  • Requirements dropped after sign-off are recorded as decisions, not deleted
  • Commits and pull requests reference requirement keys

03Access control

Most serious findings in small products live here. Test by changing IDs and removing sessions, not by reading the UI.

  • Every route that reads or writes private data checks the session
  • Admin actions check a role or permission, not only that someone is signed in
  • Changing an ID in a URL or request cannot reach another account's data
  • API tokens are scoped, and revoking one takes effect immediately
  • Password reset, invite and magic links expire and work only once

04Secrets and configuration

Check the history as well as the current tree. A key deleted in a later commit is still published.

  • No keys, tokens or passwords in the repository or its history
  • Environment files are ignored by version control
  • No server secret is exposed to the browser bundle through a public variable
  • Production and development use different credentials
  • Leaked or shared credentials have been rotated

05Dependencies

Use an advisory database such as npm audit or OSV and record the advisory IDs. Do not rely on memory.

  • Known advisories checked, with IDs recorded for anything found
  • Lockfile committed and used in the build
  • Unmaintained or abandoned packages noted
  • Install scripts from new dependencies reviewed

06Input handling

Anything a user can send is untrusted, including headers, file names and webhook bodies.

  • Database queries are parameterised, never built from strings
  • No eval or dynamic code execution on user input
  • User content is escaped before rendering
  • Uploads are checked for type and size, and stored outside the web root
  • Server-side fetches of user-supplied URLs are restricted
  • Public forms have rate limits or abuse protection

07Money paths

Rank anything here above everything else. A bug that charges twice or credits twice costs money every hour it is live.

  • Payment and order handlers are idempotent: a retry does not charge twice
  • Webhook signatures are verified before anything is trusted
  • Prices and amounts are computed on the server, never taken from the client
  • Refunds, credits and vouchers cannot be spent twice under concurrent requests

08Reliability and operations

What happens on a bad day, and whether anyone would know.

  • Errors are reported to monitoring that someone reads
  • Backups exist, and a restore has actually been tried
  • Database migrations are applied before the code that depends on them ships
  • Scheduled jobs are safe to run twice

09It is live

An audit of something nobody outside the team can reach has not finished.

  • Deployed and reachable by someone who does not work here
  • Production URL or store listing recorded
  • Sign-up and the core flow work in production, not only locally

10Findings log

One row per failed check. Rank by what costs money or exposes data first. A finding without evidence is an opinion; leave it out or go and get the evidence.

Severity: Critical, High, Medium, Low or Info

IDSeverityWhereEvidenceReproduceSuggested fixStatus
F-001[Critical][path/file.ts:42][What shows the problem][Steps][Change to make]Open
F-002[High][Route or file][What shows the problem][Steps][Change to make]Open

11Verdict

Pass, or another iteration. There is no partial pass.

  • Result: [Pass / Another iteration]
  • Open findings: [Count by severity]
  • Follow-up work: [Where the fixes are tracked]
  • Next audit: [Date or trigger]

Atrix AI

Do this with Atrix AI

Atrix AI does not scan your code. It answers the first section of this checklist, the one teams usually skip: whether what was built is what was agreed. The rest of the audit is yours to run, and its findings become tracked work.

  • Freeze what was agreed

    Accept your requirements and freeze them as a numbered baseline. The baseline keeps the exact wording and the documents as they stood, so later edits cannot quietly rewrite what was signed off.

  • See the coverage

    For every requirement in the baseline, Atrix shows whether work exists, is in progress or is done, and flags requirements that were changed, dropped or deleted after the freeze. Every state is computed from your records, not from a model's opinion.

  • Track findings as work

    Log each finding from this checklist as an issue on the project board, with a priority, and break requirements that have no work into issues. Coding agents receive the requirement keys in the handover bundle, so their commits can be traced back.

FAQ

Questions, answered

What does a code audit check?

Two things. First, whether the build matches the requirements that were agreed. Second, whether it is safe to run: access control, secrets, dependencies with known advisories, input handling, payment paths and operational basics such as monitoring and backups.

How is a code audit different from a code review?

A code review looks at a change before it merges. An audit looks at the whole system at a fixed commit, against a fixed scope, and produces findings with evidence and a pass or fail verdict.

When do I need a code audit?

Before a launch or store submission, when outside developers or a coding agent hand work back, before due diligence, and after large changes to authentication, payments or data access.

What makes a finding useful?

A severity, an exact location, evidence that shows the problem, steps to reproduce it and a suggested fix. Without evidence it is an opinion and should not be in the log.

Is the checklist free?

Yes. Copy it or download it as Markdown without signing up.

Keep exploring

Run the whole company from one place.

Start on the free plan. Bring your team, your calendar and your code when you are ready.

Start freeSee pricing