Web App Security Audit Checklist: 25 Checks Before Launch

Quick answer: This checklist organizes 25 review points across authentication, authorization, data handling, and operations. Adapt it to the application’s requirements and combine supported automated findings with code review and tests. Completing the list does not establish that every vulnerability has been found.

By Gabriel CA · Kraftwire Software

This checklist groups review tasks into authentication, authorization, data protection, API handling, infrastructure, dependencies, and monitoring. Review the application’s actual exposure, investigate findings, and identify coverage gaps.

AI Security App Review: The Reality of Vibe-Coded Software

Review generated code and deployment configuration independently of whether visible features work.

Apply the same security requirements to generated and manually written code. The scan corpus does not measure model priorities or establish why a finding occurred.

Why You Need a Security Audit Checklist for AI Apps

Use the checklist to organize review of actual controls and application-specific tests.

A checklist prompts a structured review of generated code; it cannot guarantee that data leaks are prevented. According to AppSec Santa, teams scoring low on security assessments should prioritize Code Security and Authentication as their first line of defense.

1. How Do You Audit Authentication?

Test authentication and session behavior alongside authorization and other controls. Weak authentication is a risk, but it does not make every other protection irrelevant.

Critical Authentication Checks

• Password Policy: Set and enforce a policy appropriate to the authentication method, including length and compromised-password checks.
• Session Management: Rotate session identifiers at authentication or privilege changes. For cookie-based sessions, HttpOnly limits script access and Secure limits transmission to secure connections; these flags do not prevent all XSS effects.
• Multi-Factor Authentication (MFA): Test that the required authentication assurance is enforced for administrative actions, not merely enabled in a dashboard.
• Brute Force Protection: Review account and network-based throttling, recovery paths, and abuse resistance. Rate limits reduce opportunities for abuse but do not guarantee prevention.

This illustrative attempt-count helper is not a complete lockout system. Enforce the result in the login path, record attempts reliably, handle concurrency, and consider shared-IP denial of service and distributed attacks. Its thresholds are example choices.

2. How Do You Audit Authorization?

Authentication verifies identity; authorization decides whether a particular operation is allowed. Test access to resources belonging to different users with authorized test accounts.

Critical Authorization Checks

• Row-Level Security (RLS): Where the design uses PostgreSQL RLS, inspect privileges, policies, and bypass roles. Disabled RLS leaves access to table privileges; enabled RLS without applicable policies denies rows to subject roles. Permissive policies can expose rows. See the RLS guide.
• IDOR Protection: Test reads and writes using separate authorized test accounts and resources with different ownership. An identifier alone is not authorization.
• Server-Side Authorization: Verify privileged actions against trusted server-side identity and permission data. Client-side role state is not authoritative.

3. How Do You Audit Data Protection?

Review transport security, storage access, encryption, and key management according to the data and threat model. Investigate certificate and header findings; an audit does not guarantee discovery before exploitation.

Critical Data Protection Checks

• Encryption in Transit: Check HTTPS behavior and certificate validity. The SSL checker reports supported certificate and connection observations; use appropriate protocol testing for a full TLS-version assessment.
• HSTS Headers: Review Strict-Transport-Security and its scope. Browsers enforce a learned HSTS policy on later requests; first-contact protection requires prior knowledge, such as a valid preload entry.
• Encryption at Rest: Review storage encryption, access control, and protection of encryption keys. Choose application-level encryption where the threat model requires it.
• Data Minimization: Collect and retain only the data the application needs.

4. How Do You Audit API Security?

Review input handling and output use at API boundaries, including how untrusted data reaches interpreters or the browser.

Critical API Checks

• Input Validation: Validate the expected structure and types of untrusted inputs. Separately use parameterized queries, safe interpreter APIs, and context-appropriate output handling; schema validation alone does not prevent injection.
• Rate Limiting: Apply limits appropriate to request cost, identity, and infrastructure capacity, and test their failure behavior.
• Error Handling: Return appropriate client errors without exposing internals, and redact sensitive values from logs.

These are alternative catch-clause fragments for an existing handler, not a standalone program. Redact sensitive fields before internal logging; a generic client response does not make unrestricted error logging safe.

5. How Do You Audit Your Infrastructure?

Review deployed configuration alongside code. Keep privileged credentials server-side, inspect public artifacts, and investigate supported findings from the security scanner.

Critical Infrastructure Checks

• Environment Variables: Keep secrets such as STRIPE_SECRET_KEY and OPENAI_API_KEY out of client artifacts. The secret scanner checks supported public inputs for recognizable secrets, including exposed .env content.
• CORS Configuration: Review which origins may read responses in browsers. Access-Control-Allow-Origin: * can be appropriate for intentionally public, non-credentialed resources; CORS is not authentication or general request blocking.
• Security Headers: Review Content-Security-Policy with the CSP evaluator. CSP can limit some injection effects; it does not replace safe output handling.
• Email Security: Review SPF, DKIM, and DMARC for sender authorization, message signing, and domain-alignment policy. They do not guarantee inbox placement or prevent every phishing message.

6. How Do You Audit Dependencies?

Verify dependency identities, versions, maintenance status, and known vulnerability reports before deployment. A suggested package name is not evidence that the package is legitimate.

Critical Dependency Checks

• Automated Audits: Run supported checks such as npm audit or yarn audit and investigate advisories. Coverage depends on the package data and vulnerability sources used.
• Maintenance: Review the project’s maintenance and response history; time since a release alone does not establish safety or abandonment.
• Licenses: Review license obligations for the application’s intended use.

7. How Do You Audit Logging and Monitoring?

Review whether logging and alerts provide enough evidence to investigate relevant events. Monitoring complements preventive controls; it is not the only way to stop an attack.

Critical Monitoring Checks

• Audit Logs: Record relevant authentication and permission events with appropriate retention, access control, and tamper resistance. Avoid logging credentials or unnecessary personal data.
• Alerting: Investigate unusual authentication failures in context; they do not by themselves establish a bot attack.
• Uptime Monitoring: Use uptime monitoring for supported availability observations. It does not prevent outages or establish that security controls work.

A 25-Point Security Audit Checklist

Adapt these review points to the application’s requirements. They are not a complete proof of security.

Authentication & Identity

Step 1

Password policy selected for the authentication method and enforced consistently.

Step 2

Passwords checked against known breach lists (HIBP).

Step 3

MFA enforced for all administrative and high-privilege roles.

Step 4

Cookie-based session settings reviewed, including HttpOnly, Secure, and whether SameSite=Lax fits the workflow. CSRF defenses tested separately.

Step 5

Session inactivity and maximum lifetimes chosen for the application’s risk and usability requirements.

Step 6

Rate limiting active on all login, signup, and password reset endpoints.

Authorization & Access Control

Step 7

Database privileges and, where used, RLS policies tested with the relevant roles, including Supabase’s anon role and bypass cases.

Step 8

Object-level authorization tested for the relevant read and write operations.

Step 9

Role-based access control (RBAC) logic verified on the server side.

Step 10

Public project keys distinguished from privileged credentials; the associated roles and backend access rules reviewed.

Data Security

Step 11

Full-site HTTPS with a valid, non-expired SSL certificate.

Step 12

HSTS policy reviewed; enable includeSubDomains only when all covered subdomains support HTTPS.

Step 13

Sensitive storage, encryption, key management, and access controls reviewed against the threat model.

Step 14

Database backups are encrypted, tested, and stored off-site.

API & Input Integrity

Step 15

Strict schema validation (e.g., Zod) on all incoming API payloads.

Step 16

Protection against NoSQL/SQL injection and XSS (Cross-Site Scripting).

Step 17

API error messages are generic and do not leak system or stack info.

Step 18

CORS response-access policy matched to the resource’s intended audience; authentication and CSRF defenses tested independently.

Infrastructure & Deployment

Step 19

No secrets (API keys, DB strings) present in the frontend JavaScript bundles.

Step 20

Security-header values reviewed for the application, including CSP, framing policy, and MIME-sniffing protection.

Step 21

DNSSEC and CAA records configured for the root domain.

Step 22

SPF authorizes intended sending systems, DKIM signing and validation are tested, and DMARC alignment and the intended policy are reviewed. The DMARC policy values are none, quarantine, or reject; they are not modes for SPF or DKIM.

Maintenance & Monitoring

Step 23

Known high and critical advisories reported by npm audit investigated and resolved or explicitly assessed under the project’s release policy.

Step 24

Centralized logging active for all authentication and authorization failures.

Step 25

Real-time alerts configured for unusual traffic spikes or mass data exports.

How Often Should You Perform an AI Security App Review?

Repeat review after changes that affect security-sensitive behavior and before release:

• Supported Scans: Use SimplyScan for supported deployed-URL findings and investigate changes in results.
• Application Tests: Review authorization and database policies when relevant code or configuration changes.
• Release Review: Apply this checklist alongside requirements specific to the application.

Measure performance separately from security testing; slow behavior does not establish a security defect or its cause.

Related Free Tools for Your Audit

SimplyScan offers these tools for supported checks:

• Security Headers Scanner · Inspect returned security headers.
• Email Security Tester · Review supported SPF, DKIM-selector, and DMARC DNS observations.
• Exposed Files Finder · Probe supported paths such as .env, .git, or docker-compose.yml; a clean result does not establish that every file is private.
• JWT Debugger · Decode supplied token fields and inspect supported algorithm information; decoding alone does not verify authenticity.
• CORS Tester · Inspect supported CORS response headers; it does not verify application authorization.

Browse our free tools and use their findings alongside application-specific review.

Aggregate Scan Figures

These live figures describe all scanned sites. They do not establish prevalence for an AI-built subgroup, compare development methods, or attribute findings to AI generation.

30% of the 119 live sites SimplyScan has scanned (36 sites) have at least one high or critical security issue.

13% of the 119 live sites SimplyScan has scanned (15 sites) have at least one high-severity web-security issue, such as a missing Content-Security-Policy or HSTS header.