Security Stuff You Can't Ignore (Even If You Don't Understand It)

Security is the part of building where my eyes used to glaze over the fastest. Words like "authentication," "authorization," "row-level security," "API keys" — they all sounded like they belonged to someone else's job. Someone with a hoodie and three monitors.

Then I almost shipped an app with the database wide open to the whole internet.

You do not need to become a security expert. You do need to not do the handful of obviously dumb things. Here's the shortlist I now do without thinking.

1. Never put a secret in your code.

A "secret" is anything ending in "key," "token," "password," or "secret." If you paste it directly into a file, congratulations, it's now visible to anyone who ever looks at your project. Use the environment variables / secrets storage your platform gives you. If the AI asks for a key and offers to just paste it into the code, say no. Every time.

2. Turn on the thing called "row-level security" (or whatever your platform calls it).

This is the setting that says "users can only see their own data." Without it, User A can, with the right link, read all of User B's stuff. This is not a theoretical concern. This is how most of the "startup leaked its entire database" news stories happen. Turn. It. On. And when the AI adds a new table, ask it — every single time — "did you add row-level security policies for this?"

3. Never store passwords yourself.

If your app has logins, use the built-in authentication service your platform gives you. Do not build your own. Do not "temporarily" store passwords in your database while you figure it out. I don't care how tempting it looks. This is one of the very few places where "roll your own" will actually ruin your life.

4. Check what your app is sending to the browser.

Anything your app sends to the user's browser is visible to that user, forever. So if your "admin dashboard" is fetching the full list of users and their emails and then just hiding the ones the current user shouldn't see — congratulations, you've leaked all the emails. The rule: only fetch what the user is allowed to see. Filter on the server, not in the browser.

5. When you don't know, ask the AI to audit.

Every couple of weeks I paste this prompt in and read the answer carefully: "Audit this project for security issues a non-technical builder would miss. Focus on exposed secrets, missing access controls, and anything that could leak user data. Be blunt." You will get a real, useful list. Fix the important stuff first.

A gentle warning: the AI, left to its own devices, will sometimes build the fastest version of a feature rather than the safe version. It's not malicious. It's just optimizing for "does it work" over "is it locked down." Your job as the non-technical human in the room is to say, out loud, before you ship: "and is this locked down properly?" That one sentence, added to every feature conversation, will save you.

What I'd tell someone in my shoes: you don't have to understand how the locks work. You just have to remember to lock the doors. The AI knows how the locks work. You just have to be the person who remembers to ask.