The Website Security Checklist for AI-Built Apps (2026)

AI tools compressed “idea to shipped app” from months to a weekend. What they didn’t compress is the list of things that make an app safe to put in front of strangers. This is that list — twelve checks, ordered by how badly it goes wrong when they’re skipped.

Work through it top to bottom. The first five are where AI-built apps actually get burned.

1. No server secrets in the browser

Everything you ship to the frontend is public — every visitor downloads your JavaScript. Build tools inline whatever environment variables your code touches, and AI assistants love referencing env vars in client components.

Check: search your built bundle (not your source) for sk_live, service_role, sk-ant, AKIA. On Next.js, audit every NEXT_PUBLIC_ variable: is each one truly safe to publish?

Fix: move secret-using calls into server routes; rotate anything that ever shipped. Details: API keys in your JavaScript bundle.

2. Row Level Security actually on

Supabase’s anon key is public by design — RLS is the real gate. AI scaffolds tables fast and skips policies just as fast. Same story for Firebase rules.

Check: in Supabase, every table should show RLS enabled with explicit policies. Then verify from outside: call your REST endpoint without auth and confirm you get nothing back.

Fix and background: Supabase security: RLS, anon keys, and the service_role mistake.

3. Nothing sensitive at guessable paths

Bots request /.env, /.git/config and /backup.sqlfrom every domain on the internet, continuously. If a deploy artifact or copied repo left one reachable, it’s already been fetched.

Check: request those paths on your own domain. A correct setup returns 404/403 for all of them.

Fix: Exposed .env and .git files.

4. Every input treated as hostile

SQL injection didn’t retire; it moved into fast-generated CRUD endpoints. Anywhere user input meets a query, a shell command, or raw HTML is a place to slow down.

Check: look for string-built SQL and unparameterized queries; look for dangerouslySetInnerHTML and unescaped rendering of user content.

Fix:parameterized queries / your ORM’s safe API everywhere; validate input at every API boundary (schema validation, not vibes); escape output by default.

5. Authentication on every mutating route

AI assistants generate beautiful API routes and forget that anyone on the internet can call them directly — your UI is not an access control.

Check: list every route that creates, updates or deletes data. Each one needs an auth check andan ownership check (“is this user allowed to touch this row?”) server-side.

Fix: centralize auth in middleware; add per-object authorization; rate-limit mutations.

6. HTTPS configured, not just present

Your host probably gave you a certificate. That’s not the same as TLS done right: legacy protocols enabled, missing redirect, cert quietly expiring next month.

Check & fix: SSL/TLS mistakes that still break websites.

7. Security headers set

One config block buys you browser-enforced defense: CSP against injected scripts, HSTS against downgrades, frame-ancestors against clickjacking.

Check & fix: HTTP security headers explained.

8. Cookies hardened

If your session cookie is missing HttpOnly, any XSS bug becomes account takeover. If it’s missing Secure or SameSite, you’ve left older attack classes open too.

Check & fix: Cookie security: Secure, HttpOnly, SameSite.

9. CORS: allowlist, not wildcard

“Fixed” CORS errors have a way of becoming origin: true with credentials — which quietly lets any website read your API as the logged-in user.

Check & fix: CORS misconfigurations.

10. Email authentication published

Without SPF, DKIM and DMARC, anyone can send email as your domain — and Gmail will increasingly refuse the mail you do send.

Check & fix: SPF, DKIM, DMARC.

11. DNS hygiene: no dangling records

Deleted the old staging app but kept the CNAME? Someone can claim that subdomain and serve phishing under your brand.

Check & fix: Subdomain takeover.

12. Dependencies current

Your app is mostly other people’s code. Known CVEs in popular packages (lodash, jsonwebtoken, axios, next itself) are the lowest-effort attack there is, because the exploit is public documentation.

Check: npm audit / pip-audit; pin and update on a schedule, not on incident.

Why “small” issues still matter

Attackers chain findings: a version header picks the exploit, permissive CORS reads the session, a missing cookie flag walks it out the door. Automated tools try these combinations against every reachable site — there is no “too small to target.” That’s why every item on this list deserves a real answer, not a “probably fine.”

How BoringSec checks all of this

This checklist is, roughly, our scanner registry in article form. BoringSec publishes 20 base URL modules plus 3 verified-owner background engines; each scan runs the modules applicable and authorized for that target. Coverage includes bundle-secret detectors, live Supabase/Firebase verification, exposed-path probes, headers, TLS, DNS/email auth, cookies, CORS, subdomain-takeover fingerprints, dependency CVEs via OSV.dev and more — and scores the result A++ to F, with evidence attached to every finding. Anything critical caps the score at 30, and anything we can’t prove gets downgraded rather than dramatized. Built specifically for AI-built apps; methodology documented here.

FAQ