Database & API Security
Everything backend · Supabase Row-Level Security, Firebase rules, MongoDB hardening, and API authentication patterns that keep your data private.
- Supabase Security Checklist: Protect Your Database in Production · Supabase is not secure by default: you must enable RLS on every table (the anon key is public, so tables without policies are open to anyone), keep the service role key out of frontend code, enable email confirmation and leaked-password protection, lock storage buckets with policies, and restrict Edge Function CORS to your domain.
- Row Level Security (RLS) Policies Explained for Beginners · Row-Level Security (RLS) is a PostgreSQL feature that makes the database itself enforce which rows each user can read or modify, using policies like auth.uid() = user_id. In Supabase apps the frontend talks directly to the database, so RLS is the only thing protecting your data · 38% of AI-built apps get it wrong.
- Architecture Security Risks: Exposed Database Strings, Missing Rate Limiting & More · Architecture flaws create vulnerabilities no code-level fix can patch. The most dangerous in AI-built apps: database connection strings bundled into the client, missing rate limiting on login and API endpoints, security decisions made in the frontend, zero security headers, one shared key for everything, and no logging to detect attacks.
- FlutterFlow Security Guide: Firebase Rules, Auth, and Data Protection · FlutterFlow apps inherit their security from Firebase, and the defaults ship wide open: permissive Firestore rules let anyone read or modify your database with just your project ID. Replace allow-all rules with ownership checks, enable App Check, restrict API keys, lock down Storage uploads, and validate input server-side before launch.
- Xano Security Guide: API Authentication, RBAC, and Backend Protection · Xano ships enterprise-grade security · AES-256, SOC 2, JWT auth, RBAC, rate limiting · but most of it is opt-in. New API endpoints are callable by anyone until you enable authentication per API group. Priorities: turn on auth everywhere, use auth.id instead of user_id inputs to stop IDOR attacks, and lock CORS to your frontend domain.
- Firebase Security Checklist: Protect Your AI-Built App · Firebase ships with permissive defaults: Realtime Database test mode is open to everyone and Firestore test mode expires after 30 days. Lock down Firestore, Realtime Database, and Storage rules to deny-by-default, require auth checks in Cloud Functions, restrict API keys by referrer, and enable App Check before launch.
- MongoDB Security Guide: Protect Your NoSQL Database · Secure MongoDB by fixing the failures AI-generated code repeats: authentication disabled in Docker configs, the database bound to 0.0.0.0, NoSQL injection through $gt operators in login queries, connection strings committed to git, and apps running as root. Enable auth, bind to localhost or use Atlas, cast inputs to strings, and validate every write.
- API Security Best Practices for AI-Built Applications · Every API endpoint is a public attack surface: callers can send any request, not just what your frontend allows. Secure AI-generated backends with authentication on every sensitive endpoint, schema-based input validation, parameterized queries, per-endpoint rate limits, object-level authorization checks, locked-down CORS, and generic error messages that reveal no internals.
- JWT Security: How to Read a Token and Catch the Red Flags · No, a JWT is not encrypted · it is signed. Anyone holding a token can base64url-decode the header and payload in seconds, so security comes entirely from server-side verification: reject alg none, pin the algorithm, check exp, keep secrets long and random, store tokens in httpOnly cookies, and never put sensitive data in the payload.
- CORS Misconfigurations That Leak User Data (and How to Test For Them) · A CORS config that reflects any request origin while sending Access-Control-Allow-Credentials: true lets any malicious site your logged-in users visit read their private API data. AI generators create this constantly to silence console errors. Fix it with a hard-coded origin allow-list, and test server-side with crafted Origin headers · browser dev tools can't detect it.
- Is FlutterFlow Safe? Your Firebase Rules Are the Real Attack Surface · Yes, FlutterFlow is safe · the builder and platform are not the weak point. Your Firebase security rules are: a FlutterFlow app is exactly as secure as the rules on its Firestore database and storage buckets, and the most common failure is shipping test-mode rules that let anyone read and write everything.
- Is It Safe to Expose Your Supabase Anon Key? Yes · With One Condition · Yes · the Supabase anon key is designed to be public and ships in every frontend bundle. It only grants what your Row Level Security policies allow, so the real risk is a table with RLS disabled, not the visible key. The service_role key is different: if that ships client-side, rotate it immediately.
- Webhook Signature Verification: Stop Trusting Unsigned Payloads · Verify every webhook by computing HMAC-SHA256 of the raw request body with your shared signing secret and comparing it to the provider's signature header using a timing-safe function. Add a five-minute timestamp tolerance and event-ID deduplication for replay protection. Without this, anyone who can send an HTTP POST can forge Stripe or GitHub events to your endpoint.
- AI API Security · Protecting LLM-Powered Apps, Keys, and Endpoints · AI API security covers two attack surfaces: the LLM APIs your app calls and the endpoints you build around them. Keep OpenAI, Anthropic, and Gemini keys server-side behind an edge-function proxy, set spend caps and rate limits, sanitize model output, and treat prompt injection as a path to key and data leaks.
Browse other categories: Platform Security Guides · Vulnerabilities & Fixes · Security Checklists · Comparisons & Reviews · Speed & Performance · AI Coding Security · Security Fundamentals
All security guides