Security Guides

Bolt.new ships AI-generated code with frontend API keys and unprotected endpoints. Concrete steps to audit, migrate secrets to env vars, add server-side API routes, and harden Bolt output.

Bolt.new frequently places OpenAI/Stripe keys directly in frontend files. Find them, rotate immediately, and migrate to server-side routes or env vars before attackers harvest them.

Cursor may suggest paste-a-key-here patterns that end up in production bundles. Scan deployed JS for sk-/sk_live_/AIza patterns, rotate leaked keys, and refactor to server-side calls.

Firebase Studio scaffolding often ships with permissive rules and Admin SDK usage patterns that need review. Per-scaffold hardening for Gemini-generated Firebase apps.

Each Firebase service (Firestore, Realtime Database, Cloud Storage, Cloud Functions, Hosting) needs its own security config. Per-service rules examples and Admin SDK isolation patterns.

Firebase Studio-generated code sometimes ships Admin SDK credentials to the client. Audit Gemini-generated files, rotate exposed keys, migrate admin operations to Cloud Functions.

Firebase client API keys are public by design (security lives in Rules), but Admin SDK credentials must never reach the browser. How to audit which kind you have and contain any leaks.

Replace Firebase test-mode rules with production rules: enforce request.auth.uid == resource.data.userId, use Emulator Suite to validate, handle Storage rules, and deploy via CLI.

Firebase Studio scaffolds with permissive rules by default. Migrate to production rules with ownership checks for Firestore and Storage, verify with firebase emulators:exec.

Before hitting firebase deploy: replace test-mode Rules, verify Admin SDK stays server-side, run Emulator Suite checks, and enforce production-only environment variables.

Wire Firebase Authentication into Gemini-generated Firebase Studio apps: set up Email/Password or OAuth providers, update Security Rules to require auth.uid, and protect Cloud Functions.

Eight-step hardening of a Lovable + Supabase app: enable RLS on every table, move OpenAI/Stripe keys to Edge Functions, configure vercel.json headers, rate-limit via kv store.

Lovable apps commonly leak OpenAI, Stripe, and third-party keys in the browser bundle. Rotate compromised keys and migrate sensitive calls to Supabase Edge Functions with Deno.env.

Row Level Security is off by default in Lovable + Supabase projects. Enable RLS on every table, write SELECT/INSERT/UPDATE/DELETE policies scoped to auth.uid(), and verify with a client probe.

Full Supabase Auth setup for Lovable: enable email verification, pick OAuth providers, wire protected routes, and align RLS policies with (select auth.uid()) for authenticated data access.

Netlify-specific hardening via _headers, netlify.toml environment scoping, Functions secret isolation, and edge middleware for auth. Common Netlify misconfigurations and fixes.

netlify.toml is committed to git — any secret there is exposed. Scan build logs, move secrets to Netlify UI environment variables, rotate anything that leaked, and isolate per-deploy scope.

Netlify deploy hardening: configure _headers with CSP/HSTS, scope environment variables per-deploy-context, protect Functions endpoints, and enable access control on preview builds.

Replit's shared environment and public-repl defaults create unique risks. Migrate credentials to Replit Secrets, ensure repls are private, add headers, and prevent accidental code exposure.

Public repls with .env files or hardcoded keys are instantly indexable. Migrate to Replit Secrets, make the repl private, rotate anything that was ever visible, and remove from git history.

Replit deployment checklist: make repl private before deploy, migrate .env to Replit Secrets, authenticate all exposed endpoints, and remove accidentally-committed keys from history.

End-to-end Supabase hardening: enable RLS with ownership checks, keep service_role out of the client, authenticate RPC functions, and lock down storage bucket policies.

The Supabase anon key is meant to be public (RLS enforces security). Service role is not. Tell them apart, rotate the service role if it ever touched a client bundle, and move to server-only.

Comprehensive Supabase RLS guide: enable RLS, write policies using (select auth.uid()) to avoid initplan warnings, handle service_role bypass, test with different auth contexts.

Complete Supabase Auth guide: email/password with verification, Google/GitHub/OAuth providers, getServerSession for SSR, and RLS policy patterns that pair with auth.uid()/role claims.

Vercel app hardening: configure security headers in vercel.json, enable Vercel Authentication for previews, correctly scope Development/Preview/Production env vars.

Vercel env vars have Development/Preview/Production scopes — and the wrong scope leaks secrets to previews. Audit build logs, rotate exposed keys, and use NEXT_PUBLIC_ only where intended.

Vercel deployment hardening: configure security headers in vercel.json, enable Vercel Authentication for preview deployments, scope env vars correctly, and monitor build logs for leaked secrets.

Windsurf's Cascade can introduce paste-a-key patterns in generated code. Scan Cascade-edited files for key patterns, rotate leaked credentials, and enable ZDR to reduce future exposure.

Per-environment scoping (dev/preview/prod), secret managers (AWS Secrets Manager, Doppler), avoiding NEXT_PUBLIC_ leaks, and keeping .env out of git history permanently.

Generate new key → deploy with new key alongside old → verify traffic moved → revoke old. Per-provider rotation steps for OpenAI, Stripe, AWS IAM, and Supabase service role.

Implement 2FA that users will actually enroll in: TOTP via Speakeasy/Google Authenticator, WebAuthn for passkeys, recovery codes, and UX patterns that survive phone loss scenarios.

Choose bcrypt (cost 12+) or argon2id (m=64MB, t=3) based on constraints. Migrate from weak hashes by rehashing on next login. Avoid MD5, SHA1, and plain SHA256 — none are password hashes.

OAuth 2.0 done right: PKCE for SPAs (code_verifier + S256), validate state parameter to prevent CSRF, enforce strict redirect_uri allowlists, and scope tokens minimally.

Railway deployment hardening: use private networking between services, isolate env vars per service, add auth to TCP proxies, and verify public ingress is intentional.

Railway's service model exposes unique hardening points: per-service env vars, private networking between services, TCP proxy auth, and image-based deployment risks.

Production API hardening: JWT or session auth on every route, rate limiting by user/IP, Zod/Joi input validation, and response shape normalization to prevent info leaks.

File uploads need layered defense: extension + magic-number validation, size caps, AV scanning for user-facing files, isolated storage buckets, and never serve from the same origin.

Configure cookies that resist session hijacking: HttpOnly blocks JS access, Secure enforces HTTPS, SameSite controls cross-site sending, Partitioned isolates third-party contexts.

Lock down database access: force TLS 1.2+, use connection pools to limit exposure, rotate credentials on a schedule, and verify pg_hba.conf / MongoDB Atlas rules block unauthorized ranges.

Supply chain hygiene: automated vulnerability scanning with npm audit / Snyk, pin versions with exact lockfiles, generate SBOMs for compliance, and watch for suspicious package renames.

Block iframe-based attacks: CSP frame-ancestors (modern), X-Frame-Options (legacy), sandbox attribute for legitimate embeds, and why JavaScript framebusting alone is bypassable.

Multi-layer defense: per-IP and per-account rate limiting, progressive delays, account lockout thresholds, invisible CAPTCHAs for suspicious traffic, and credential-stuffing detection.

WebSockets skip CORS — validate Origin manually on upgrade. Authenticate with a JWT in the upgrade query string, rate-limit per connection, validate every incoming message with Zod/Joi.

Configure security headers for Next.js App Router: headers() function in next.config.js for static headers, middleware.ts for nonce-based CSP, and per-route overrides where needed.

Stop CORS blocking your fetch() calls: allowlist specific origins (never `*` with credentials), handle OPTIONS preflight, tune Access-Control-Max-Age, and avoid the common reflection mistake.

Defense in depth for XSS: framework auto-escaping, CSP with script-src strict, DOMPurify for rich content, and the list of escape hatches (dangerouslySetInnerHTML, v-html, |safe) to audit.

Parameterized queries are the fix — but ORMs have unsafe escape hatches (raw(), DB::raw, find_by_sql). How to audit your stack, use the safe idioms, and lock down table/column name inputs.

CSRF patterns that actually work: synchronizer token for server-rendered apps, double-submit cookie for SPAs, SameSite=Lax cookie defaults, and API-style apps with per-request origin check.