The Complete Application Security Checklist for 2026

Quick answer: A complete application security checklist covers eight domains: authentication and access control, API keys and secrets, database rules and RLS, security headers and CSP, injection and input validation, dependencies, monitoring and logging, and deployment hygiene. Work through each list before launch, rerun it after every significant change, and automate the repeatable checks with a scanner.

By Paula C · Kraftwire Software

What Should an Application Security Checklist Cover?

An application security checklist earns its keep by covering the places where apps actually get breached, not by being long. For a modern web app that means eight domains: authentication and access control, API keys and secrets, database rules, security headers and CSP, injection and input validation, dependencies, monitoring and logging, and deployment hygiene.

This page is the master appsec checklist. Each section below is a question you should be able to answer with evidence, followed by the concrete checks. Work through it top to bottom before launch, then reuse it as your web security checklist for every significant release. If your app was built with an AI tool like Lovable, Bolt, or Cursor, the vibe coding security checklist adds the platform-specific traps on top of this one.

Every line item here is a security control, so if you arrived searching for an application security controls checklist or a best practices checklist, this is the same list under a different name. The categories map to the OWASP Top 10, which is the closest thing to a universal application security standard most teams need.

How Do You Secure Authentication and Access Control?

Broken access control sits at the top of the OWASP Top 10, and it is the failure mode AI builders most often leave behind: the frontend hides a page while the API behind it stays wide open.

• Every sensitive route and API endpoint enforces authorization on the server · frontend route guards are UX, not security
• Admin checks live in database policies or server code, never in a React component or a localStorage flag
• Passwords are hashed with bcrypt, scrypt, or Argon2 · never stored in plaintext or with reversible encryption
• Session tokens expire, and logout and password changes invalidate them
• Login, signup, and password-reset endpoints are rate-limited against brute force
• Password reset uses single-use, expiring tokens
• MFA is available for accounts that can cause real damage (admin, billing)

Are Your API Keys and Secrets Actually Secret?

Your built JavaScript bundle is public. Anything in it · keys, tokens, connection strings · is public too.

• No secret keys in frontend source files or the built bundle (grep the dist output, not just src)
• Environment variables prefixed VITE_, NEXT_PUBLIC_, or REACT_APP_ contain only publishable values
• Third-party calls that need secret keys go through a server-side function
• .env files are gitignored and were never committed · check git history, not just the working tree
• Any key that ever appeared in a commit has been rotated, not just deleted
• Development, staging, and production use separate keys

The environment variables security guide covers the VITE_ prefix trap and key rotation in detail.

Is Your Database Protected at the Database Layer?

If your app uses Supabase or Firebase, your database is directly reachable from the internet with a public key. The only thing between an attacker and your tables is your policy configuration.

• Row-Level Security is enabled on every table (Postgres/Supabase) or security rules cover every collection (Firebase)
• Policies scope reads and writes to auth.uid() or equivalent, with separate policies per operation
• The service role key or admin SDK credentials never appear client-side
• You have tested direct API access as an unauthenticated user and as a second user trying to read the first user's data
• Database functions with elevated privileges set an explicit search_path
• Backups run automatically and you have tested a restore at least once

Platform-specific versions of this section: the Supabase security checklist and the Firebase security checklist.

Which Security Headers and CSP Rules Do You Need?

Headers are the cheapest hardening you will ever do: a few lines of configuration that shut down whole attack classes.

• Content-Security-Policy restricts script sources · start with default-src 'self' and loosen deliberately
• Strict-Transport-Security with max-age=31536000 forces HTTPS on every future visit
• X-Content-Type-Options: nosniff stops MIME-type confusion attacks
• X-Frame-Options: DENY (or frame-ancestors in CSP) blocks clickjacking
• Referrer-Policy: strict-origin-when-cross-origin keeps full URLs out of third-party logs
• CORS allows only your own origins · never a wildcard combined with credentials

Test your live site in seconds with the free security headers checker, and read the CSRF and security headers guide for what each header actually blocks.

How Do You Prevent Injection and Validate Input?

Injection covers SQL injection, XSS, and command injection · all three come from trusting user input.

• Every database query is parameterized or goes through an ORM · no string-concatenated SQL anywhere
• Every endpoint validates input on the server with a schema library like Zod · client-side validation is a convenience, not a control
• No eval(), new Function(), or dangerouslySetInnerHTML with user-controlled data
• User-generated HTML is sanitized before rendering
• File uploads are validated by content and size, not just file extension
• Error responses return generic messages · stack traces and query details stay in server logs

React-specific XSS patterns get their own list in the React security checklist.

Are Your Dependencies Introducing Vulnerabilities?

Your app inherits the vulnerabilities of everything in package.json.

• npm audit (or your ecosystem's equivalent) runs in CI and critical or high findings block the release
• The lockfile is committed so builds are reproducible
• Unused packages are removed · every dependency is attack surface
• Packages handling auth, crypto, or payments are actively maintained
• Package names suggested by AI assistants are verified before install · hallucinated or typosquatted names are a real supply-chain vector

What Should You Monitor and Log After Launch?

A checklist run tells you about today. Monitoring tells you about tomorrow.

• Failed login attempts are logged and alert someone past a threshold
• Server-side errors are captured centrally, not printed to a console nobody reads
• Uptime monitoring pings your app and alerts you before your users do
• Logs never contain passwords, tokens, or full payment data
• Admin and destructive actions leave an audit trail (who, what, when)
• Alerts go to a channel someone actually watches

Is Your Deployment Hygiene Up to Standard?

• HTTPS is enforced and HTTP redirects with a 301
• Debug modes, verbose errors, and test endpoints are disabled in production
• Staging and preview environments are password-protected or blocked from indexing
• .git directories, .env files, and database dumps are not reachable over HTTP
• Old preview deployments holding real data are deleted
• A security.txt file tells researchers where to report bugs

Audit, Hardening, or Risk Assessment: Which Checklist Do You Need?

People search for an application security audit checklist, an application hardening checklist, and an application risk assessment checklist as if they were three separate documents. Add security assessment and vulnerability assessment to the pile. In practice they are one list used three ways.

• Audit checklist · point-in-time verification. You walk the list and record evidence that each control passes or fails. A web application security audit checklist like our 25-check pre-launch audit is this mode, and the mechanics are identical whether you call it a website security audit checklist or a lightweight app audit checklist.
• Hardening checklist · the to-do version. Every failed audit item becomes a hardening task: add the header, enable RLS, rotate the key. Hardening reduces attack surface through configuration rather than code rewrites.
• Risk assessment checklist · the prioritization version. You score each failed item by likelihood and impact. An exposed service role key is critical (near-certain exploitation, total data loss); a missing Referrer-Policy header is low. A vulnerability assessment checklist is the scanner-driven variant of the same exercise: find weaknesses first, then rank them.

Run the audit to find gaps, the risk assessment to order them, and the hardening pass to close them. Same checklist, three passes.

How Do You Turn the Checklist Into a Repeatable Security Review?

An application security review checklist only works if it runs more than once. Three habits make it stick:

• Trigger it on events, not memory: before launch, after any feature touching auth, payments, or data access, and on a quarterly calendar slot.
• Keep the completed checklist in your repo next to the code, dated, so you can diff reviews and see what regressed.
• Review AI-generated diffs against the same list · the Cursor security checklist shows how to make that a habit when an agent writes most of your code.

Here is a condensed application security checklist template you can paste into a file or a tracking issue:

Can You Automate the Application Security Checklist?

Most of it, yes. Exposed keys, missing headers, RLS gaps, XSS and CSRF patterns, leaked environment variables, and deployment mistakes are all machine-checkable. SimplyScan runs 51+ automated checks across 14 categories in about 30 seconds against your live URL · free, no signup, and the free scan includes 2 rescans so you can verify fixes. The 60 free standalone tools cover single checks like headers, DNS, and JWT decoding when you want to test one thing quickly.

What automation cannot judge is your business logic. Whether user A should ever see user B's invoice is a question only you can answer, which is why the manual review pass never fully disappears. Automate the mechanical half of this checklist so your review time goes to the judgment half.

Run the automated half of this checklist now · then work through the rest with the template above.