Security Review Checklist | freecodeaudit.com

What this template is

This is a security-focused review checklist for web applications and APIs. Where a general code audit checklist also covers quality, tests, and performance, this one goes deeper on the attack surface: how someone gets in, what they can reach once inside, and whether you would notice.

It is written for the engineer assigned to “do a security pass” before a launch, a fundraise, or an enterprise deal, and for teams answering a security questionnaire who want to verify their claims instead of guessing. Copy the markdown into your tracker, work top to bottom, and attach evidence (command output, a curl transcript, a screenshot of a config) to each checked box.

1. Secrets and key management

Repo history is clean: gitleaks detect --source . -v returns nothing (full procedure in the secrets scanning tutorial)
Client-side code and built bundles contain no server keys, database URLs, or private certificates
Secrets live in environment variables or a secrets manager; nothing is hardcoded
Every engineer offboarded in the last year triggered a credential rotation, or shared credentials do not exist
API keys are scoped to least privilege (a key that only needs read access cannot write)

2. Authentication

Passwords are hashed with argon2, bcrypt, or scrypt, with per-user salts
Login, signup, and password reset are rate limited and return identical errors for “wrong password” and “no such user”
Password reset tokens are random, single-use, and expire within an hour
MFA is available for user accounts and mandatory for admin accounts
Session tokens are httpOnly, Secure, and invalidated on logout and password change

3. Authorization and access control

Every endpoint that takes a resource ID verifies ownership server-side: test with curl as user A against user B’s IDs
Role checks happen in the API layer, never only in the UI
Vertical escalation is blocked: a regular user calling an admin endpoint gets 403, verified by test
Multi-tenant data is scoped by tenant ID in the query layer, not filtered after fetch
Internal admin panels are behind SSO or VPN, not just an unlisted URL

4. Injection and input handling

All SQL goes through parameterized queries or an ORM; zero string-built queries in the codebase
Rendered user content is escaped by default; every use of innerHTML or dangerouslySetInnerHTML is justified and sanitized
File uploads validate content type server-side, cap size, and are served from a separate domain or with Content-Disposition: attachment
User-supplied URLs (webhooks, imports, avatars) cannot reach internal addresses: block private IP ranges and cloud metadata endpoints
Shell commands never interpolate user input; if unavoidable, arguments are passed as arrays, not strings

5. Transport and headers

TLS everywhere; HTTP redirects to HTTPS and HSTS is set
Content-Security-Policy exists and blocks inline script, or there is a written plan to get there
X-Frame-Options or frame-ancestors prevents clickjacking on authenticated pages
Cookies carry SameSite=Lax or stricter
CORS allows specific origins, not * on credentialed endpoints

6. Dependencies and supply chain

npm audit, pip-audit, or the ecosystem equivalent shows no unaddressed critical or high CVEs (the dependency audit tutorial covers all major ecosystems)
Lockfiles are committed and CI installs from them exactly
CI pipelines pin third-party actions and images by hash or exact version
No install scripts run from untrusted packages without review

7. Logging, monitoring, and response

Authentication events (login success, failure, password change, role change) are logged with actor, timestamp, and source IP
Logs never contain passwords, session tokens, or full card numbers
An alert fires on error-rate spikes and on repeated authentication failures
Someone is on the receiving end of those alerts and knows what to do
There is a written one-page incident response plan: who rotates keys, who notifies users, who talks to customers

How to act on the results

Triage failures by exposure first: anything an unauthenticated attacker can exploit (leaked secret, injection, missing auth on a public endpoint) is a drop-everything fix. Authenticated-attacker issues (broken object-level authorization, escalation) come next, within days. Hardening items (headers, CSP, logging) are real but can ride the normal sprint cadence. The vulnerability classes in sections 1 through 4 account for most of the serious findings we see in real audits; the breakdown in top security vulnerabilities code audits catch shows how they get exploited in practice, and how to prioritize fixes after an audit gives the full triage model.

Rerun sections 1 and 6 monthly; they decay fastest. Rerun the whole list before each major release.

Want us to run it for you (free)

A checklist verifies the known failure modes; it cannot reason about your specific permission model, your tenant isolation, or the endpoint your team forgot exists. A Webisoft engineer can. Submit your repository and we will run this exact security lens over it manually and send you a prioritized report, free: get a free code audit.