You built and shipped an app with AI or no-code tools, and now you keep bumping into words you do not fully understand. A tool warning mentions "exposed secrets." An article says to add "rate limiting." Your database dashboard has a toggle labeled "RLS." You can tell these words matter, but you cannot tell which ones mean "fine for now" and which mean "stop and get help."
This is a glossary you can skim, not study. Each term gets one plain sentence and one concrete example from a small solo app, so when a word shows up in a warning you can look it up in a few seconds and know what you are looking at. It is built to sit open next to the security self-audit these terms support while you work through your app.
How to use this glossary during an audit
Do not read this top to bottom like a textbook. When you hit an unfamiliar word during a review, search this page for it, read the one-line definition and the example, then go back to what you were doing.
The terms are grouped by what you are actually doing when you meet them: controlling who gets in (access), protecting what you store (data), and understanding the warnings tools throw at you (attacks). At the end there is a short list of terms that, when they appear in a real warning about your live app, are a signal to slow down and bring in a professional.
One thing up front: knowing these words does not make your app secure. It makes you able to read a warning and act on advice. The doing still comes from the checks in the security self-audit these terms support and from fixing the nine mistakes where these terms appear.
Access terms: who gets in and what they can do
These are the words around logins, permissions, and traffic.
Authentication is confirming who a user is, usually with a login. Example: when a customer types their email and password to reach their dashboard, that check is authentication.
Authorization is deciding what a logged-in user is allowed to do. Example: a signed-in free user can view their own orders but not open the admin billing page. Authentication is "are you who you say you are"; authorization is "are you allowed to do this."
Session is the temporary state that keeps a user logged in after they sign in, so they do not re-enter a password on every page. Example: after login, a session cookie in the browser lets someone move between your app's pages for an hour without signing in again.
Rate limiting is capping how many times someone can hit an action in a short window. Example: allowing five login attempts per minute, then making the sixth wait, so a script cannot try thousands of passwords. Signup forms, login, and password reset are the common places to add it.
RLS (Row-Level Security) is a database rule that limits each user to only their own rows of data. Example: in a shared table, RLS makes sure user A can only read the rows tagged as user A's, even if a query asks for everything. Many no-code and backend tools ship with this off by default, which is worth checking.
Data terms: what you store and how you protect it
These words come up around databases, user information, and configuration.
PII (Personally Identifiable Information) is any data that can identify a real person. Example: a name plus email address, a phone number, or a home address stored in your users table. If you are unsure what counts, what counts as personal data walks through it in plain terms.
Encryption is scrambling data so it is unreadable without a key. You will see two flavors: "in transit" (protected while moving over the network, which is what HTTPS gives you) and "at rest" (protected while stored). Example: your app being served over HTTPS means a customer's password is encrypted in transit as they log in.
Secrets are the private keys and passwords your app uses to talk to other services. Example: your Stripe API key or your database password. These should never appear in front-end code or be pasted into a chatbot; what secrets are and why they leak covers how they escape and how to spot it.
Environment variables are the standard place to store secrets outside your code, so the values are not written into files you might share. Example: instead of typing your API key directly into a script, you save it as an environment variable named something like STRIPE_SECRET_KEY and the code reads it from there.
Hashing is a one-way scramble used for passwords, so even you cannot read them back. Example: your app stores a hashed version of each password; when someone logs in, it hashes what they typed and compares, without ever keeping the plain password. If a tool says passwords are "stored in plain text," that is the opposite and a problem.
Attack terms in plain English
These are the words in scary-sounding warnings. You do not need to know how to perform any of these. You need to recognize the name so you know what a warning is pointing at and can look up the fix.
Injection is when input a user types gets treated as commands instead of plain data. Example: a search box that, instead of just searching, ends up running a database instruction hidden in what someone typed. The defense is having your tools handle input safely, which most modern platforms do by default when used as documented.
XSS (Cross-Site Scripting) is when input from one user causes code to run in another user's browser. Example: someone puts a script into a public comment field, and it runs when other visitors load the page. The fix is making sure user content is displayed as text, not executed.
CORS (Cross-Origin Resource Sharing) is the browser rule about which other websites are allowed to call your app's back end. Example: a CORS error in your browser console usually means your front end and back end are on different addresses and the permission is not set up, not that you are under attack. It is often a configuration message, not a break-in.
CSRF (Cross-Site Request Forgery) is tricking a logged-in user's browser into making a request they did not intend. Example: a user is signed into your app, visits a bad link elsewhere, and their browser is nudged into performing an action on your app. Most current frameworks include protection you mainly need to leave enabled.
Which terms signal "stop and get help"
Some words are fine to handle yourself with a checklist. Others, when they show up in a real warning about your live app, mean the stakes are high enough to bring in a security professional rather than guess. Treat the following as escalation signals:
| Term in a real warning | Why it means escalate |
|---|---|
| Injection (SQL or command) | Can expose or destroy your whole database; hard to confirm you have fully fixed it |
| Exposed secret / leaked API key | Someone may already have your keys; needs rotation and a review of what was reached |
| PII or payment data at risk | Personal and card data carry legal and financial duty; get qualified help |
| Authentication or authorization bypass | Means the wrong people can reach the wrong data; a core control has failed |
| Passwords stored in plain text | Every account is exposed if the data leaks; needs a proper fix, not a patch |
A good threshold: if the warning touches logins, payments, or personal data, and you cannot clearly explain what changed and why it is now safe, that is the point to hire a professional. This is educational, not legal or compliance advice; for payments and personal data, verify your specific situation with a qualified professional. Because these definitions map to real controls, having your setup reviewed by a security professional is recommended before you rely on it.
In Plain English
This post is a quick-reference glossary of the security words that show up in AI-tool warnings and dashboards, each defined in one sentence with one solo-app example. It helps non-technical builders who have already shipped something and keep meeting jargon like injection, CORS, secrets, or rate limiting without knowing what is serious. Use it by keeping it open during an audit and searching for a word the moment you hit it, rather than reading it end to end. What to do next: run the actual checks in the guide audit, and when a warning touches logins, payments, or personal data and you cannot explain the fix, escalate to a professional. Remember that recognizing the words is step one, not proof your app is safe.
Keep it handy
Bookmark the full glossary and keep it open next to the Security Self-Audit while you work through your app. When a term here connects to a real check, follow it into the audit and fix one thing at a time. You can also browse the Secure hub for the rest of the "secure what you shipped" walkthroughs.
Kodbe is an independent commercial publication about maintaining and owning software built with AI or no-code tools. It is not affiliated with Kodbe Inc, Kodobe, Kodable, or Kodu.