BACKEND SECURITY

Why backend security is where AI-generated apps fall over

Frontend mistakes are visible — a missing CSP shows up in any browser scanner, an exposed Stripe secret screams in the bundle. Backend mistakes are silent. Row Level Security off on a Supabase table looks identical to RLS on, until somebody queries the public REST endpoint with the anon key. An admin route without an auth check returns 200 to anyone who knows the path.

AI coding tools are particularly prone to backend gaps because the controls live in places the model can’t see when generating: in Postgres policies, in Firestore rules, in middleware that has to be wired into every route. The model writes the route handler, ships the schema, and skips the policy file. The app works. The tests pass. The data is open.

Three patterns drive most of what we find:

• Wide-open data layer. RLS disabled on Supabase, allow read, write: if true; in Firestore, anon-readable tables containing PII.
• Missing auth checks on individual routes. Login is gated; /admin/users is not. The middleware was applied to one router and not another.
• Errors that leak everything. Default Express stack traces, ORM queries echoed in 500 responses, environment variables in debug output.

All three are cheap to fix once you know to look. The hub below points at the specific guides.

Pick your stack

You’re building on	Start here	Then add
Supabase	Supabase RLS Guide	Authorization patterns, Auth implementation
Firebase	Firebase Security Rules	Database security best practices, API security guide
Custom REST/GraphQL	API Security Guide	API abuse protection, Auth implementation
Serverless (Lambda, Edge)	Secure Serverless SaaS Architecture	Runtime protection, Data encryption
Anything storing regulated data	Compliance Checklist	Data encryption, Database best practices

Database and data layer

• Supabase RLS Guide — complete Row Level Security implementation. Per-table policies, common pitfalls, verification queries. Pair with the free RLS checker to confirm your policies actually work from the anon key’s perspective.
• Firebase Security Rules — Firestore rules at scale: per-collection policies, custom claims, App Check enforcement, the request.auth vs request.resource gotchas. Pair with the free Firebase scanner.
• Database Security Best Practices — universal principles that apply across Postgres, MySQL, MongoDB: least-privilege roles, connection-level encryption, audit logging, backup encryption, schema-level controls.

API surface

• API Security Guide — protecting endpoints in AI-generated backends: auth middleware patterns, rate limiting, input validation, CORS done right, error handling that doesn’t leak.
• API Abuse Protection — credential stuffing, scraping, business-logic abuse. Detection patterns and the layered controls (rate limits, anomaly scoring, captcha) that actually reduce abuse without breaking real users.

Authentication and authorization

• Authentication Implementation — secure session management, password handling, JWT pitfalls (alg: none, secret-key confusion, missing audience checks), MFA wiring, and the OAuth flows that AI tools tend to misimplement.
• Authorization Patterns — RBAC vs ABAC, attribute-based policies, row-level vs object-level enforcement, the IDOR/BOLA failure modes that pass code review but fail real-world testing.

Runtime and architecture

• Runtime Protection for SaaS — what can be done after the code is in production: WAF rules, request signing, anomaly detection, runtime application self-protection (RASP), and where each is worth the operational cost.
• Secure Serverless SaaS Architecture — Lambda and Edge Function patterns: cold-start credential leakage, IAM scoping, VPC boundaries, the “functions can call each other but shouldn’t” failure mode.

Compliance and encryption

• Data Encryption Guide — encryption strategies for sensitive data at rest, in transit, and in use. Field-level encryption, envelope encryption, key rotation, and what AWS KMS / GCP KMS / HashiCorp Vault each buy you.
• Compliance Checklist — concrete GDPR and SOC2 requirements, mapped to specific backend controls. Not the legal interpretation — the engineering checklist.

The 80/20 backend hardening pass

If you have one afternoon, do these in order — they catch the majority of what we see in production:

1. Confirm RLS / Firestore rules are not if true. Read every policy file. If a table is exposed via a public anon key, the policy is the only thing keeping it private.
2. Audit your auth middleware coverage. List every route. For each, name the middleware that enforces auth. Routes without a named middleware are unguarded — fix or document why public.
3. Lock down error responses. Replace default error handlers with one that returns {error: 'Internal error', requestId} and logs the full detail server-side. No stack traces, no SQL, no env vars.
4. Enable rate limiting on auth routes. Login, signup, password reset, MFA challenge. 20 attempts per IP per 15 minutes is a reasonable starting point.
5. Pin JWT verification to specific algorithms. algorithms: ['RS256'] (or whatever you actually use). Without this, alg: none and HS256-with-pubkey-as-secret are both accepted.
6. Audit secrets in code. Grep for sk_live_, AKIA, eyJ, xoxb-, ghp_. If any are in committed code, rotate them. Move to a secret manager.
7. Confirm prod data isn’t in dev/staging. A staging DB seeded with a prod snapshot is a prod DB with a worse perimeter.

Each maps to a specific guide above. Run a full app scan afterwards to verify.

Common mistakes

• Treating the SDK’s anon key as “frontend-safe” without RLS. It is safe only if RLS is enforced on every table. Without RLS the anon key is a database admin key shipped to every visitor.
• Adding auth middleware to a router but missing a sibling router. Express’s app.use(auth) doesn’t propagate to app.use('/admin', adminRouter) if the latter is wired before. Check the order, then check every router.
• Returning rich error objects from catch blocks in production. Anything from error.message is potentially sensitive. Whitelist what you return; default to “Internal error” + a logged request ID.
• Using service_role keys in Edge Functions because “they have to bypass RLS”. They don’t always have to. Threading the user’s JWT through preserves RLS — preserve it unless you have an explicit reason not to.
• Putting compliance work last. GDPR and SOC2 controls overlap heavily with the security baselines above. Doing them together is half the work of doing them serially.

Related resources

• Free Supabase RLS Checker — verify your policies before merging.
• Free Firebase Scanner — same idea, Firestore + Storage + Functions.
• Vibe Code Scanner — full app probe that ties backend findings back to the route they showed up on.
• Token Leak Checker — confirms you didn’t ship a service-role key in the bundle.
• Agentic Coding Security — controls for code an agent wrote, with backend specifics.