The AI Security Glossary Every Vibe-Coding Founder Needs

TL;DR: This AI security glossary defines 69 terms in plain English, from anon key to zero-day. Each entry is 2–3 short sentences. It tells you what the term means, and why it can sink an AI-built app. Learn the database terms first — that is where most vibe-coded breaches start.

Vibe coding tools write apps that work. They do not explain the security layer they skipped. And they do not define the words your first audit report will use. So founders learn what "service role key" means at 2 a.m., after the leak. This page exists so you learn it now instead.

Each term below is something we check for real. We scanned 100 AI-built apps. The average score: 42/100. The gaps behind those scores map to a short list of words. Want your own number first? Run the free scan on your live URL. Then read on.

The five terms behind most low scores

Before the full list, a shortcut. These five terms explain most of the points lost in the apps we scan. If you only act on five entries, act on these.

You can test two of these right now. Our header checker and rate limit checker run against any live URL.

A – B

• Alerting: A ping that fires when something looks wrong, like a spike in failed logins. Without alerts, breaches get found by customers, not by you.
• Anon key: The public Supabase key your frontend ships to each browser. It is meant to be seen. It is only safe when RLS limits what it can reach.
• API key: A password for a third-party service, like payments or email. Private keys must never sit in frontend code. If one leaks, rotate it first, investigate second.
• Article 50: The EU AI Act transparency rule. Users must be told when they are talking to an AI. It applies from August 2, 2026. Fines run up to €15 million or 3% of global turnover.
• Attack surface: Each point where an outsider can touch your app. Each route, form, key, and vendor adds to it. Smaller is safer.
• Audit trail: A record of who did what in your system, and when. Big buyers ask for it. So does the law.
• Breach notification: The legal duty to report a data breach. Under GDPR the window is often 72 hours. Know your deadline before you need it.
• Brute-force attack: Guessing passwords over and over until one works. Rate limits on login routes are the direct fix.
• Bug bounty: Paying friendly hackers to report the flaws they find. Most early startups are not ready for one yet. Learn the term anyway; buyers mention it.

C

• Clickjacking: Your page gets loaded in a hidden frame on some other site. Users click things they cannot see. The X-Frame-Options header blocks it.
• Code review: A human reads the change before it ships. It is the step most vibe-coding workflows skip. It is also where AI mistakes get caught.
• Consent management: You record what each user agreed to, and honor it. The cookie banner is the part you see. The stored record is the part that counts.
• CORS: The rules that decide which sites may call your API from a browser. A wildcard setting lets any site on the web do it. Our CORS guide shows how this goes wrong in AI-built apps.
• CSP (Content Security Policy): A header that tells the browser which scripts may run on your page. Without one, a single injected script runs with full access. It is your best shield against XSS.
• CSRF: Tricking a logged-in browser into sending a request the user never meant to make. AI-generated forms often ship without the token check that stops it.
• CVE: A public ID for a known software flaw. CVE-2025-48757 is a live example: missing RLS exposed data in 170+ Lovable-built apps.

D

• DAST: Testing your running app from the outside, the way an attacker would. It finds what code reading cannot. Our scans work this way; no code access needed.
• Database connection string: The full address and password for your database in one line. In a public repo or a browser bundle, it is game over. RLS cannot save you then.
• Data retention policy: A written rule for how long you keep user data before you delete it. AI builders never write this for you. The law expects it.
• DDoS: Flooding an app with traffic until it falls over. Rate limits and a CDN are the first line of defense.
• Dependency scanning: Checking the packages you installed against known flaws. AI tools often pick old package versions. Nobody reviews them unless you do.
• DPA (Data Processing Agreement): A contract with any vendor that handles personal data for you. If you call an AI API with EU user data, you likely need one signed.

E – H

• Environment variable: The right home for a secret. It stays out of committed code. AI tools often hardcode the secret instead; that is the bug.
• EU AI Act: The EU law for AI systems. Its transparency duties start on August 2, 2026. Our EU AI Act guide for SaaS founders covers what small teams must do.
• Excessive agency: An AI system holding more power than its task needs. Database write access "just in case" is the classic case. Scope it down.
• GDPR: The EU data protection law. It follows your users, not your office. Our GDPR guide for vibe-coded apps covers the gaps AI builders leave.
• Hallucination: An AI saying something false with a straight face. In a user-facing bot, that is a legal and trust problem, not a quirk.
• HSTS: A header that forces browsers to load your site over HTTPS only. It blocks downgrade attacks. One line at your host sets it.

I – L

• Incident response plan: The steps your team takes the moment a breach is confirmed. Write it now. Writing it during the breach is too late.
• Insecure output handling: Running AI output without checking it. Code, HTML, or SQL from a model is untrusted input. Treat it that way.
• Jailbreaking: Tricking a model into dropping its safety rules. A bot with no guardrails can be talked into leaking its own system prompt. Test yours.
• JWT (JSON Web Token): A signed token that proves who a user is. If your server never checks the signature, anyone can forge one. Where you store it matters too; see our guide on JWTs in localStorage.
• Lawful basis: Your legal reason to use personal data under GDPR, such as consent or contract. The app works without it. The law does not.
• Least privilege: Give each key, role, and agent the least access it needs. It shrinks the blast zone when something leaks. It costs nothing.
• Logging: A record of what happened in your system. Without it, "what did they take?" has no answer. With it, an incident becomes a report.

M – O

• MFA (Multi-Factor Authentication): A second proof at login, like a code from an app. It is the cheapest big security win. Most vibe-coded apps ship without it turned on.
• Model poisoning: Corrupting the data a model learns from, so it goes bad later. It matters most if you fine-tune your own models.
• Monitoring: Watching errors, uptime, and odd events around the clock. It is one of the four things we score. About half the apps we scan have none.
• OAuth token: The token you get after "Log in with Google" and friends. Keep it short-lived and refreshed. Do not hoard it in local storage.
• OWASP Top 10: The standard list of the ten biggest web app risks. There is now a separate Top 10 for LLM apps. Prompt injection leads that one.
• Owner-scoped policy: An RLS policy that checks the row belongs to the requesting user. "Any logged-in user" is not a boundary. This phrase separates a real policy from a decorative one.

P – R

• Password hashing: Storing a one-way scramble instead of the password itself. If your database leaks, hashes buy you time. Plain text ends firms.
• Pen test: A human expert tries to break in, by hand. It digs deeper than machine scans. It is also slower and pricier. Do the scan first; it is the cheap 80%.
• Privacy policy: The public page that says what data you collect and why. A template copied from another site does not match your real data flows. The law notices.
• Prompt injection: Hiding commands inside user input to hijack what your AI does. It is the top-ranked risk on the OWASP list for LLM apps. Any bot that reads user text is exposed.
• Public bucket: A storage bucket anyone can read without logging in. Fine for logos. A breach for ID documents and invoices.
• Rate limiting: A cap on how many requests one user or IP can make. It stops brute force, scraping, and surprise API bills. Test any endpoint with our rate limit checker.
• RBAC (Role-Based Access Control): Access granted by role: admin, editor, viewer. Without it, each logged-in user may quietly reach admin routes.
• RLS (Row Level Security): The Postgres feature that limits which rows each user can see. "Enabled" alone means nothing; the policies do the work. Start with our guide to Supabase RLS policies.

S

• Same-origin policy: The browser rule that keeps one site's script out of the next site's data. CORS pokes holes in it on purpose. Bad CORS pokes holes by accident.
• SAST: Scanning source code for unsafe patterns, without running the app. It catches hardcoded secrets early. It cannot see runtime problems.
• Secrets sprawl: Keys and tokens scattered across code, chat logs, and config files. AI sessions make it worse. Each session mints new keys. Central storage plus rotation is the fix.
• Security headers: The response headers that set browser guardrails: CSP, HSTS, X-Frame-Options, and friends. Most AI-built apps ship with none. Test yours with our free header checker.
• Service role key: The Supabase master key. It bypasses RLS entirely, so it belongs on the server and nowhere else. The difference matters: read anon key vs service role key.
• Session hijacking: Stealing a live session token to become that user, no password needed. Secure cookie flags and short sessions shrink the risk.
• Signed URL: A private-file link that expires. It grants access for minutes, not forever. It is the right way to share private uploads.
• Slopsquatting: Malware hiding under a package name AI tools tend to invent. Your builder suggests the package; you install it. Check every unfamiliar name before adding it.
• SOC 2: An audit framework for how a firm guards client data. Enterprise deals often require it. We prep you for it; we do not certify it.
• SQL injection: Sneaking database commands in through user input. It is decades old and still everywhere. Prepared statements end it.
• SSO (Single Sign-On): Login through an existing account like Google or Microsoft. It hands the password problem to a firm that handles it well.

T – Z

• TLS: The encryption between a browser and your server. Hosting platforms mostly handle it now. Custom domains can still slip through, set up wrong.
• Training data leakage: Private data in a training set coming back out through clever prompts. The risk is highest for fine-tuned in-house models.
• Uptime monitoring: A steady check that your app is up and reachable. Downtime and security incidents often trip the same wires.
• Vendor risk: The risk you inherit from each third-party tool you use. Your AI API, email service, and payment processor are part of your attack surface now.
• Vulnerability scanning: Machine probes of your live app for known weak spots. It is the fastest baseline you can get. Our free scan is exactly this, scored out of 100.
• WAF (Web Application Firewall): A filter that blocks known attack patterns before they reach your app. Few apps need one on day one. Growing traffic changes that math.
• X-Frame-Options: The header that stops other sites from framing your page. It is the anti-clickjacking control. One line to add.
• XSS (Cross-Site Scripting): Injecting a script that runs in other users' browsers. It is one of the web's oldest attacks. It still shows up in fresh code all the time. CSP plus output encoding is the fix.
• Zero-day: A flaw the vendor does not know about yet, already in use by attackers. You cannot patch what has no patch. Layers — headers, least privilege, monitoring — limit the damage.

Why founders need these words at all

The numbers say the gaps are the default, not the rare case. Symbiotic Security scanned 1,072 AI-built apps. 98% had at least one flaw. 16% had critical issues. CMU's SusVibes study put it at 61% of AI-written code with at least one flaw. Our own scans of 100 apps averaged 42/100. The tools are good. The defaults are not.

You cannot fix what you cannot name. When a contractor says "RLS is on," you now know what to ask. Are the policies owner-scoped? Or is it USING (true) pretending to be a lock? You can even check RLS yourself with our Supabase RLS checker.

Want the full picture? Our vibe coding security guide walks the whole path from first scan to launch-ready. The RLS deep dive lives in our Supabase RLS guide.

What checking all of this costs

The free scan is $0. The full Launch Readiness Audit is $499 one time. You get a branded PDF with each finding and a ranked fix plan with time estimates. You also get a benchmark against 200+ audited apps and a senior review of each finding. Ongoing monitoring starts at $149/mo. The compliance terms above — GDPR, Article 50, SOC 2 — get their own check in our Compliance Wing.

FAQ