The 2026 Web Security Checklist for AI-Built Applications

Quick answer: Use this checklist to review database access, secret handling, browser protections, and session security in AI-built applications. Inspect generated code and deployed behavior, and test permitted and denied operations instead of treating a working interface as evidence of security.

By Paula C · Kraftwire Software

Include architecture review alongside code generation. Adapt the web security checklist to the application’s actual data flows and threats.

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.

11% of the 119 live sites SimplyScan has scanned (13 sites) have at least one medium-severity architecture issue, such as a library with a known vulnerability or no rate limiting.

How Should You Review an AI-Built App?

Review generated code and deployed configuration independently of visible functionality. Test the security controls the application requires.

Read security-sensitive code and test relevant behavior before deployment. Use architecture security guidance to trace boundaries and data flows.

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

Investigate individual findings and their check definitions before attributing a cause or interpreting the aggregate category.

How Do You Secure the Database Layer in AI-Built Apps?

For Supabase, inspect grants and RLS policies. For Firebase, review Security Rules for client access and IAM for privileged server access. Test allowed and denied operations.

1. Review Row Level Security (RLS)

Enable RLS on Supabase tables exposed through the Data API and define policies for the intended access. With RLS disabled, access depends on table privileges. Enabled RLS without applicable policies denies rows to roles subject to RLS; permissive policies can expose rows, and bypass roles ignore RLS. A predicate such as (role = 'authenticated') does not necessarily test the requesting role; its meaning depends on the referenced value. An ownership condition such as (auth.uid() = user_id) fits only tables whose access model uses that owner identifier. See RLS policies explained.

2. Validate Firebase Security Rules

Inspect the deployed rules rather than assuming test settings suit production. In Firestore rules, request.auth != null checks for an authenticated request but does not by itself authorize a particular document. Review resource.data for existing document conditions and validate proposed writes using the appropriate request data. Test allowed and denied operations.

Are Your API Keys Leaking Through the Frontend?

SimplyScan checks fetched public assets for recognizable secret patterns, subject to coverage limits.

Inspect build output and responses for sensitive configuration values exposed to the browser.

• Server-Side Only: Keep privileged OpenAI, Anthropic, and Stripe credentials out of browser output. Do not use client-exposed prefixes such as NEXT_PUBLIC_ or VITE_ for secrets.
• Proxy Requests: Route operations requiring privileged credentials through an authorized server endpoint. Intentionally public browser APIs need their documented restrictions.
• Key Scoping: A public Supabase anon key is not interchangeable with a secret service credential. Review Supabase grants and policies and each provider’s supported key restrictions.

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.

8% of the 119 live sites SimplyScan has scanned (10 sites) have at least one high-severity exposed-secret issue, such as an API key or a hardcoded password in the page's code.

Use our secret scanner to investigate supported patterns in supplied inputs. A clean result does not prove there are no exposed credentials.

Configure security headers using supported mechanisms such as next.config.js where applicable, and inspect deployed responses. Headers complement safe output handling and application controls.

• Content Security Policy (CSP): Configure and test supported resource and execution restrictions using the CSP guide; a policy does not prevent every XSS attack.
• Strict-Transport-Security (HSTS): Establishes an HTTPS policy in supporting browsers after it is learned or through preloading.
• X-Content-Type-Options: The nosniff value restricts MIME sniffing for relevant resource types.
• X-Frame-Options: Restricts framing according to its value; SAMEORIGIN permits same-origin framing.

For a deeper dive into these configurations, see our security headers checklist for AI apps.

How Do You Handle Authentication and Session Security?

Review authentication, authorization, session expiry, and account recovery as separate controls. Select MFA methods appropriate to the account risks.

1. Implement Appropriate Multi-Factor Authentication

Review TOTP or WebAuthn support in the authentication system and test enrollment, login, and recovery. Our TOTP generator can help test TOTP behavior with development secrets; do not share production seeds.

2. Secure Cookie Handling

For session cookies, use Secure for HTTPS transmission and HttpOnly where browser scripts do not need the value. Choose a SameSite policy for the application’s flows: SameSite=Strict can block legitimate cross-site navigation or login behavior. Test CSRF defenses separately.

3. JWT Validation

Validate signatures using explicitly allowed algorithms, and check issuer, audience, exp, and required claims such as sub before trusting a token. Use the JWT security guide and test rejection cases; a decoded token alone is not verified.

Is Performance a Security Risk for AI Apps?

Review resource consumption and abuse controls independently of page-speed scores.

79% of the 119 live sites SimplyScan has scanned (94 sites) have at least one medium-severity speed issue, such as render-blocking scripts or no route-based code splitting.

Measure expensive requests, concurrency, and resource limits when investigating denial-of-service risk. A slow response alone does not establish exploitability. Use the performance security guide to plan targeted tests.

Use a security audit checklist to organize manual review and supported automated checks.

Automated Scanning

SimplyScan provides a free URL scan with supported checks for public secret patterns, headers, and anonymous backend responses. A URL scan does not verify every RLS policy or perform cross-user authorization tests.

Dependency Audits

Review dependency versions and known vulnerabilities before deployment. Run npm audit or use a github repo scanning guide to find vulnerabilities in your supply chain.

Input Validation

Validate expected inputs, use parameterized queries, and apply context-appropriate output handling. Test untrusted data flows for code injection and XSS.

Environment Variable Audit

Regularly check your .env files. Scan the deployed bundle and repository for detectable secret patterns. Investigate findings and revoke exposed credentials; a clean result does not prove that no secrets remain. See env file linter.

What Additional Risks Apply When the App Uses an LLM?

If the application integrates an LLM at runtime, review prompt injection, output handling, and tool permissions. Using AI only to generate code does not itself create a runtime prompt interface.

• Prompt Injection: Untrusted instructions can influence model behavior. Enforce data access and tool permissions outside the model; input filtering alone is insufficient.
• Insecure Output: Treat model output as untrusted. Use safe text rendering or appropriate sanitization when intentionally supporting HTML.
• Over-Permissioning: Limit agent access to required operations and data, and validate tool calls server-side.

Use the checklist to organize configuration review and manual testing. Investigate the findings and assess risks outside automated coverage. See cursor security checklist, windsurf security guide.

• Database: Test grants, policies, and privileged access for the intended operations.
• Secrets: Keep secret credentials out of frontend code and sensitive .env files out of Git.
• Headers: Verify deployed CSP, HSTS, and framing restrictions.
• Auth: Test MFA and session handling, including Secure and HttpOnly cookie behavior.
• Infrastructure: Review email-authentication records and certificate validity.
• Performance: Investigate resource use and abuse controls without treating a page-load threshold as proof of security.
• AI Safety: Enforce permissions outside the model and treat its output as untrusted.

Review generated code and deployed behavior using the checks appropriate to your application. SimplyScan supplies supported observations to help that investigation.

Frequently Asked Questions

Which security flaw in ai-built applications should I check?

Review secret credentials, database access, server-side authorization, and browser protections. Prioritize findings by their actual impact and exposure; the aggregate scan data does not rank flaws in AI-built apps.

How do I prevent my AI tool from leaking API keys?

Keep privileged credentials server-side and out of client-exposed configuration. Inspect bundles, responses, logs, and repository history for leaks. Revoke and replace exposed credentials; a clean scanner result does not prove all secrets are safe.

Why is Content Security Policy (CSP) so important for web security?

A suitable CSP can restrict script execution and resource loading in supporting browsers. Its protection depends on the policy and application. It complements safe output handling rather than preventing every injection attack.

Is it safe to use AI-generated database schemas?

Review the schema, grants, applicable row policies, and privileged access paths against the intended data model. Test constraints and authorization independently of how the schema was generated.

How often should I run a security audit on my web app?

Choose review frequency based on changes and risk. Re-test affected controls after deployments or architectural changes, and review dependency advisories as they become available. Automated checks complement manual investigation.