The Complete Application Security Checklist for 2026

Quick answer: A complete application security checklist for 2026 covers authentication, secret management, database RLS, security headers, and input validation. With 30% of AI-built apps containing high-severity risks, you must move beyond manual reviews to automated scanning and rigorous server-side authorization to protect your users and data.

By Paula C · Kraftwire Software

To secure a modern app, you must validate authorization on the server, move all secret keys out of the frontend bundle, enforce strict Content Security Policies (CSP), and automate dependency audits.

The landscape of web security has shifted. With the rise of "vibe coding" and AI-assisted development through tools like Cursor, Windsurf, and Lovable, apps are being built faster than ever. However, speed often comes at the cost of safety. This checklist provides the rigorous framework needed to close those gaps before they are exploited.

What Should an Application Security Checklist Cover?

It must address the full stack of a modern, often serverless or AI-generated, architecture. According to recent industry reports, web application attacks continue to account for the majority of confirmed data breaches.

This checklist covers eight essential domains:

• Authentication and Access Control
• API Keys and Secrets Management
• Database Security (RLS and Rules)
• Security Headers and CSP
• Injection and Input Validation
• Dependency and Supply Chain Security
• Monitoring, Logging, and Uptime
• Deployment Hygiene and Environment Security

If you are using AI agents to write code, you are likely moving too fast for manual reviews alone. Use this list as your "definition of done" for every feature.

1. How Do You Secure Authentication and Access Control?

Broken access control is the #1 risk on the OWASP Top 10. In the era of vibe coding, AI often generates beautiful frontend "protected" routes that have no corresponding server-side checks.

• Server-Side Authorization: Every API endpoint must verify the user's identity and permissions. Never rely on frontend redirects or "hidden" buttons for security.
• BOLA Prevention: Ensure users cannot access other users' data by simply changing an ID in a URL (Broken Object Level Authorization).
• Secure Password Hashing: Use Argon2, bcrypt, or scrypt. Never store passwords in plaintext.
• Session Management: Tokens must be stored securely (HttpOnly, Secure cookies) and invalidated immediately upon logout or password change.
• Rate Limiting: Protect /login, /signup, and /reset-password from brute-force attacks.
• Multi-Factor Authentication (MFA): Require MFA for any account with administrative or billing privileges.

2. Are Your API Keys and Secrets Actually Secret?

One of the most common failures in modern web development is leaking secrets in the client-side bundle. If a key is in your main.js or .next folder, it is public.

• Frontend Grep: Search your built distribution files (not just source) for sensitive strings like sk_, key-, or AIza.
• Environment Variable Scoping: Only variables prefixed with NEXT_PUBLIC_ or VITE_ should be accessible to the browser. All others must remain server-side.
• No Secrets in Git: Use a .gitignore for .env files. If a secret was ever committed, it is compromised. You must rotate it, not just delete it.
• Proxy Third-Party Calls: If an API requires a secret key (like OpenAI or Stripe), call it from a serverless function or backend, never directly from the browser.
• Key Rotation: Establish a 90-day rotation policy for all production service keys.

Check your repo for leaks with our secret scanner or read the environment variables security guide.

3. Is Your Database Protected at the Database Layer?

For apps built on Supabase, Firebase, or Xano, the database is often exposed directly to the web. Your only line of defense is Row-Level Security (RLS).

• Enable RLS: Every single table in Postgres/Supabase must have RLS enabled.
• Policy Granularity: Create separate policies for SELECT, INSERT, UPDATE, and DELETE.
• Auth Context: Use auth.uid() or request.auth.uid to scope data access to the authenticated user.
• Service Role Protection: Never, under any circumstances, include the service_role or admin key in your frontend code.
• Search Path Security: For database functions, set an explicit search_path to prevent search-path hijacking.

For deeper dives, see the Supabase security checklist or the Firebase security checklist.

4. Which Security Headers and CSP Rules Do You Need?

Security headers are a high-leverage defense mechanism. They tell the browser how to behave safely when interacting with your site.

• Content-Security-Policy (CSP): Implement a strict CSP to prevent Cross-Site Scripting (XSS). Start with default-src 'self' and only whitelist trusted domains.
• HSTS: Set Strict-Transport-Security with a max-age of at least one year (31536000) to force HTTPS.
• X-Content-Type-Options: Set to nosniff to prevent the browser from interpreting files as a different MIME type.
• X-Frame-Options: Use DENY or SAMEORIGIN to prevent clickjacking attacks.
• CORS Configuration: Explicitly define allowed origins. Avoid using Access-Control-Allow-Origin: * for any endpoint that handles user data.

You can verify your headers instantly with the security headers checker.

5. How Do You Prevent Injection and Validate Input?

Injection remains a critical threat, especially as AI-generated code might use unsafe patterns like string concatenation for queries.

• Parameterized Queries: Use an ORM or parameterized SQL. Never concatenate user input into a query string.
• Input Validation: Use a library like Zod or Joi to validate every incoming request on the server.
• Sanitize User Content: If you must render user-provided HTML, use a library like DOMPurify to strip malicious scripts.
• Avoid Unsafe Functions: Ban the use of eval(), new Function(), and dangerouslySetInnerHTML unless absolutely necessary and sanitized.
• File Upload Security: Validate file types by magic bytes, not just extensions, and limit file sizes to prevent DoS.

6. Are Your Dependencies Introducing Vulnerabilities?

Your application is only as secure as the weakest package in your node_modules.

• Automated Audits: Run npm audit or yarn audit in your CI/CD pipeline. Block deployments if "High" or "Critical" vulnerabilities are found.
• Lockfile Integrity: Always commit your package-lock.json or yarn.lock to ensure consistent, audited builds.
• Dependency Pruning: Remove unused packages. Every line of code you didn't write is a potential entry point for an attacker.
• AI Hallucination Check: When using Cursor or Windsurf, verify that suggested packages actually exist. Attackers sometimes "typosquat" or claim names of packages AI models frequently hallucinate.

7. What Should You Monitor and Log After Launch?

Security is a continuous process. You need to know when things go wrong before your users do.

• Uptime Monitoring: Use uptime monitoring to ensure your site is reachable and performant.
• Centralized Logging: Send server errors and security events (like failed logins) to a central service (e.g., Sentry, Logtail).
• Audit Trails: Log administrative actions · who changed a permission, who deleted a record, and when.
• Alerting: Set up Slack or Email alerts for critical errors or spikes in 401/403 response codes.
• No PII in Logs: Ensure that passwords, credit card numbers, and PII are scrubbed from logs before they leave your server.

8. Is Your Deployment Hygiene Up to Standard?

The final step is ensuring the environment hosting your code is hardened.

• HTTPS Enforcement: Redirect all HTTP traffic to HTTPS using a 301 redirect.
• Environment Isolation: Use completely separate API keys and databases for development, staging, and production.
• Disable Debugging: Ensure NODE_ENV=production is set and that verbose error stack traces are hidden from end-users.
• Exposed Files: Check that .git, .env, and docker-compose.yml are not accessible via the web. Use the exposed files tool to verify.
• Security.txt: Add a security.txt file to /.well-known/ to give white-hat researchers a way to report vulnerabilities. See our security.txt guide.

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

While these terms are often used interchangeably, they serve different stages of the security lifecycle:

• Security Audit: A formal "pass/fail" review of your current state. You use this checklist to document that every control is in place.
• Hardening: The process of fixing the gaps found during an audit. For example, if your audit shows missing headers, "hardening" is the act of adding them.
• Risk Assessment: Prioritizing which fixes matter most. An exposed database is a "Critical" risk; a missing X-Content-Type-Options header is a "Low" risk.

In SimplyScan's scans of 170 AI-built apps, the average security score was 85 out of 100.

Manual checklists are prone to human error. To maintain a high security posture without slowing down development, you should automate the mechanical parts of this list.

• Scan on Every Deploy: Use the SimplyScan MCP server or GitHub integrations to trigger a scan whenever you push code.
• Monitor Uptime and Health: Set up Pro Monitoring to get 24/7 alerts on downtime or security regressions.
• Use Standalone Tools: For quick checks, use our 60+ free tools, such as the JWT debugger or CORS tester.

SimplyScan's free scanner grades 8 dimensions · security, speed, SEO, AI visibility (AEO), accessibility, GDPR signals, domain health, and email security · in about 30 seconds. It is specifically tuned to find the "vibe coding" errors that traditional scanners miss, such as exposed Supabase keys or broken AI-generated auth logic.

Run a free security scan now

Application Security Checklist Template (Markdown)

Copy this into your SECURITY.md or a GitHub Issue to track your progress:

FAQ

What is the difference between a security audit checklist and a vulnerability assessment checklist?

An audit checklist is a compliance-focused verification that specific security controls (like MFA or encryption) are present. A vulnerability assessment is a proactive search for weaknesses, often using automated tools like SimplyScan to find unpatched software or misconfigurations. Audits prove you followed the rules; assessments find the holes you missed.

How often should you run an application security checklist?

You should perform a manual review of this checklist before every major release and at least quarterly. However, automated scans should run on every deployment.

Does an endpoint security checklist mean API endpoints or devices?

In the context of application security, "endpoint" refers to your API routes (e.g., /api/v1/user). An endpoint security checklist ensures these routes are authenticated, rate-limited, and validated. In corporate IT, "endpoint security" refers to protecting physical devices like laptops and servers from malware.

What standards should an application security checklist be based on?

The industry standard is the OWASP Top 10 for general web risks and the OWASP ASVS (Application Security Verification Standard) for deep technical requirements. For modern AI-built apps, you should also include platform-specific checks for RLS (Supabase/Firebase) and environment variable hygiene.

Is an application security checklist different for AI-generated apps?

Yes. AI-generated apps (vibe coding) often have "hallucinated" security · the UI looks secure, but the underlying API is wide open. For these apps, you must place extra emphasis on Row-Level Security and server-side validation, as AI tools frequently prioritize a working UI over a secure backend.

What should a security testing checklist include before launch?

Before launch, you must verify: 1. No secret keys are in the frontend bundle. 2. RLS is active on all database tables. 3. Security headers (CSP, HSTS) are present. 4. All API endpoints require server-side auth. 5. A security.txt file is present. 6. An automated scan has been performed to catch low-hanging fruit.