IntegrAuth Academy
Identity, security and practical AI — free, from zero. Byte-sized lessons, real diagrams, hands-on labs, zero fluff. Two programs, each with its own exam and certificate.
English is hard? Your browser can translate this page into Tamil, Telugu, Kannada, Malayalam or Hindi. Tech words stay in English so you learn the real names.
How?
- Chrome on phone: ⋮ menu → Translate
- Chrome on computer: right-click → Translate to …
- Edge: the translate icon in the address bar
Build an app without coding
Sam runs a bakery. He chatted with an app builder and had an order app by lunch. Zara asks: can a stranger read Maya's order? Your goal: enjoy the speed, but check for holes.
🧪 Interactive lab — enable JavaScript to play with this one.
- Browser code is public. Keep secret keys on the server.
- The server must check who is asking.
- Row rules decide who reads which rows. Test them as a second user.
- Know what your app stores, and where.
What app builders do
An app builder is a website that makes an app from your words. Its AI writes the screens, the database and the sign-in. Building by chat, without reading the code, is often called vibe coding.
Examples, as of October 2026, in no order: Lovable, Bolt, Replit, Vercel's v0 and Google AI Studio. Dyad is an open-source one that runs on your computer. They are great for a prototype or a small tool. Real customers' data needs more care.
Four common holes
A shop window is public, but the cash box stays in the back room. Browser code is the window. The server is the back room.
Checks of public builder apps keep finding these holes:
- A secret key in the browser code. Anyone can copy it from the page's code.
- No check on the server. A stranger can skip your screens and call the server, the computer behind your app.
- Open row rules. Rules decide which rows each user may read. This is row-level security. Without them, one user can read everyone's data.
- Unknown data. The app may keep names, emails or chats you never planned for.
Now test Sam's order table as three people.
🧪 Interactive lab — enable JavaScript to play with this one.
Go deeper: public keys and secret keys
Some keys are made for browser code. A publishable key only names your project. It is safe only when the row rules are right.
Secret keys are different: payment keys, AI keys and admin database keys. With one, anyone can spend your money or read all your data. Keep them in the builder's secret store, and use them only in server code.
Watch setting names. In many web tools, names that start with VITE_ or NEXT_PUBLIC_ are copied into the browser code. Never put a secret there.
Was a secret key public, even for an hour? Deleting the line is not enough. Rotate it: make a new key and turn off the old one.
Go deeper: row rules in practice
Many builders use a hosted database, like Supabase or Firebase. Supabase calls its rules row-level security. Firebase calls them security rules. In Supabase, a table with row-level security off is often open to anyone with the publishable key.
A good rule names the owner: "a user reads only rows where owner = the signed-in user". "Signed in" alone is not enough: every signed-in user would read every row.
Test reads and changes. Can user B read A's row? Change it? Delete it? Can a visitor read anything?
Go deeper: what the checks found
In 2025, a researcher checked 1,645 apps made with a popular builder. In 170 of them, anyone could read or change data. Row rules were missing or weak. Emails, phone numbers and some keys could be seen. The builder then added a security check.
Later in 2025, a security company checked over 5,600 public builder apps. It found over 2,000 weak spots and over 400 exposed secrets. It also found personal data, like medical records.
A builder can have holes, too. In 2025, researchers found a flaw in another builder. Strangers could join its private apps. It was fixed within a day.
Go deeper: from prototype to real app
Some builders scan your app before you publish. As of October 2026, some look for tables without row rules. One builder's docs say its scan does not replace a security review. A scan can't know your own rules, like "customers see only their own orders".
Before real users arrive:
- Connect the project to git, for history and undo (Set up your coding assistant).
- Ask someone who codes to review the sign-in and the rules (Review AI-written code).
- Set spend and usage limits (Ship safely).
Go deeper: know what your app stores
Write down four things. What data does the app keep? Where, and with which company? Who can see it? How long do you keep it?
Collect only what you need. A cake order needs a name and an address, not a birth date. Customer data may fall under privacy laws. Say what you keep in a short privacy policy. Know how to delete one customer's data when they ask.
Don't just ask the builder's AI if your app is safe. It often says yes. Test it as a second user.
On a free plan, build a tiny to-do app with sign-in. Make two accounts. Can account B see account A's to-dos? Test only your own apps.