Vulnerabilities & Fixes
Deep dives on the vulnerabilities that actually hit AI-built apps · exposed keys and secrets, XSS, CSRF, injection, CORS, missing headers · each with a concrete fix.
- CVE-2025-48757 Explained: How to Check If Your Lovable App Is Affected · CVE-2025-48757 let attackers bypass authentication in Lovable apps that relied on client-side login state without database-level enforcement · tables lacking RLS policies could be read directly. The scaffolding has been patched, but existing apps must verify the fix: enable RLS on every user-data table, validate sessions server-side, and audit data access patterns.
- How to Fix Exposed API Keys in 5 Minutes · Revoke the exposed key at the provider first · bots exploit leaked keys within minutes, and deleting code does not un-leak them. Then check usage logs for abuse, move the call behind a server-side proxy such as an Edge Function or API route, store the new key without a public prefix, and add a pre-commit secret scan.
- Why Exposed API Keys in Frontend Code Are Dangerous · Every line of frontend JavaScript ships to the browser, so any secret key in it (Stripe sk_, OpenAI sk-, AWS credentials, database URLs) is public. Automated bots find exposed keys within minutes and can run up thousands in charges. The fix: rotate the key, move calls to a server-side proxy, add rate limiting.
- XSS Prevention Guide: Protect Your AI-Built App from Cross-Site Scripting · Prevent XSS by never passing unsanitized input to dangerouslySetInnerHTML or innerHTML · sanitize with DOMPurify, prefer textContent, validate link protocols to block javascript: URLs, and set a Content-Security-Policy header as a safety net. AI-generated code hits these traps often because models bypass framework escaping to make rendering work.
- CSRF Protection & Security Headers: The Missing Layer in AI-Built Apps · Six headers protect AI-built apps at the browser level: Content-Security-Policy, Strict-Transport-Security, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, and Permissions-Policy. Add them via vercel.json, Netlify _headers, or helmet, then stop CSRF with SameSite=Strict cookies or per-session tokens · AI coding tools almost never set any of this up for you.
- Code Injection Prevention: SQL Injection, eval(), and Command Injection in AI Apps · Prevent injection by never mixing untrusted input with interpreters: use parameterized queries or an ORM instead of string-concatenated SQL, cast NoSQL inputs to expected types to block operator injection, replace eval() and new Function() with safe parsers like mathjs, and run system commands through execFile so shell operators are treated as literal text.
- AI Security Risks: Prompt Injection, LLM Abuse, and API Key Exposure · AI features add three major risks: prompt injection, where user input overrides your system instructions; cost attacks on unprotected endpoints; and exposed AI API keys that can rack up thousands of dollars in hours. Defend with role-separated prompts, output filtering, authentication, per-user rate limits, max_tokens caps, and server-side keys only.
- OWASP Top 10 for AI-Built Apps: What Vibe Coders Need to Know · AI-generated apps are vulnerable to every OWASP Top 10 category, from broken access control to SSRF, because AI tools reproduce insecure patterns from their training data. The most common failures are frontend-only access control, missing input validation, shipped debug defaults, and outdated dependencies · all fixable with server-side enforcement and regular scanning.
- Environment Variables Security: Stop Leaking Secrets to Production · Environment variables only protect secrets when used correctly. Any variable prefixed VITE_, NEXT_PUBLIC_, or REACT_APP_ is embedded in your JavaScript bundle and readable by every visitor. Keep API keys, service role keys, and database URLs server-side without a public prefix, add .env to .gitignore, and verify your deployed bundle contains no secrets.
- 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.
- Content Security Policy for Vibe-Coded Apps: A Practical CSP Guide · Content Security Policy is a browser-enforced allowlist that blocks injected scripts even when sanitization fails, making it the strongest defense-in-depth against XSS. Most AI-generated apps ship no CSP, or one with 'unsafe-inline' that cancels the protection. Start with default-src 'self', use nonces or hashes for inline scripts, and roll out via report-only mode.
- DNSSEC and CAA: Stop Attackers From Hijacking Your Domain · DNSSEC signs your DNS records so resolvers reject forged answers, stopping cache-poisoning redirects. CAA records restrict which certificate authorities may issue HTTPS certificates for your domain, blocking attacker-obtained certs. Both are free: enable DNSSEC at your DNS host, publish the DS record at your registrar, then add CAA records naming only the CAs you use.
- security.txt: Give Researchers a Simple Way to Report Bugs (RFC 9116) · security.txt is a plain-text file at /.well-known/security.txt, defined by RFC 9116, that tells security researchers how to report vulnerabilities to you privately. Two fields are required: Contact and Expires. Serve it over HTTPS as text/plain, keep the Expires date current, and pair it with a short disclosure policy · setup takes about ten minutes.
- 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 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.
- How to Find Exposed Secrets in Your Code Before They Ship · Exposed secrets hide in three predictable places: frontend bundles, git history, and misprefixed .env files. Grep your code and built output for known prefixes like sk_live_, AKIA, ghp_, and BEGIN PRIVATE KEY, then run an automated secret scanner to catch entropy-based leaks. If you find one, rotate the key first · deleting code does not un-leak it.
- 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.
- DNS Records Explained: A, CNAME, MX, TXT, NS and CAA for App Builders · DNS records tell the internet where your app loads, where your email lands, and who may issue certificates for your domain. A and AAAA map names to addresses, CNAME aliases them, MX routes mail, TXT carries SPF, DKIM and DMARC, NS delegates control, and CAA restricts certificate issuance · audit all six regularly.
- Broken Access Control Checklist · Find and Fix OWASP A01 · Broken access control (OWASP A01) is when your app lets a user do something they should not · read another user's data, edit a record they do not own, or reach an admin action. This checklist groups the fixes by layer · object-level ownership checks, function-level role checks, database RLS, and verified JWT sessions.
- 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 · Database & API Security · Security Checklists · Comparisons & Reviews · Speed & Performance · AI Coding Security · Security Fundamentals
All security guides