All posts

January 10, 2026 · 4 min read

The One-Page Security Checklist for Anyone Building With AI

This is the recap post. I've been writing about a handful of things this week and I keep landing on the same idea: none of it is exotic, it's just easy to skip when you're moving fast and the app already looks finished. So here it is on one page. Bookmark it, screenshot it, whatever gets it in front of you again right before you hit publish.

Security headers and keys

Headers are the cheapest security you'll ever add, and most builders skip them because the tool they're using doesn't set them by default.

  • Set a Content-Security-Policy, even a loose one. Loose beats none.
  • Add X-Frame-Options or frame-ancestors so your app can't get quietly framed inside a phishing page.
  • Turn on Strict-Transport-Security once you're serving everything over HTTPS.
  • Never put a secret key in anything that ships to the browser. If you can view-source it, so can everyone else.
  • Check your repo's commit history for keys you pasted in and then deleted. Deleting the line doesn't delete the history. Rotate the key instead.

The RLS myth

Row Level Security gets talked about like a switch you flip once and forget. It isn't. RLS is a policy you write, table by table, and it does nothing on its own. This is the exact setting behind the Lovable disclosure from last year, where a missing or backwards policy left more than 170 live apps handing out data to anyone who asked.

  • Turning on RLS with zero policies means nobody can read the table, including you. That's not security. It's just a different kind of broken.
  • A policy that evaluates to true for every row is functionally the same as no RLS at all. Read your policies out loud sometimes, they often say less than you think.
  • Every table holding user data needs its own policy. Copying one table's policy onto a new table without checking the column names is exactly how gaps happen.
  • If your AI tool generated the schema, don't take a summary's word for it. Ask it directly to show you the policies on every table, then actually read them.

Login gaps

The login screen is the part everyone user-tests and almost nobody security-tests.

  • Request a password reset for an email that doesn't exist. The response shouldn't tell you whether the account is there or not.
  • Rate-limit login and signup. A form with no limit is an open invitation to brute force.
  • Confirm logging out actually kills the session on the server, not just clears a cookie in the browser tab.
  • If there's an admin route, make sure the check happens server-side. Hiding a button in the UI is not access control.
  • Try acting as another user by changing an ID in the URL or an API call. This exact gap, a public ID with no ownership check behind it, is what let outsiders into other people's private accounts on more than one AI-built platform last year.

Know your key types

Not every API key carries the same weight, and mixing them up is how a small mistake turns into a big one.

  • Publishable or public keys are built to live in browser code. Secret keys are not, ever.
  • Prefer a key you can scope down, read-only, single table, single bucket, over one master key that can touch everything.
  • If a platform offers a restricted-key option, take it, even when the unrestricted one is faster to wire up.
  • Keep a running list of every key your app holds and what each one can reach. If you can't recite it, you don't actually have a handle on your own attack surface.

Get a second opinion

The best bug I caught this month wasn't one I found myself. It was something a second read caught after I'd stared past it a dozen times. Your AI tool's own built-in security scan, where it has one, is a good filter. It is not a substitute for someone who wasn't in the room when the app got built.

  • Before you launch, get someone else, or a fresh AI session with no memory of the build, to look at just the auth and data-access code.
  • Ask them one question: if I had no login at all, what could I still do here? It's the fastest way to surface a hole.
  • Don't review your own code in the same sitting you wrote it. Sleep on it, or hand it to someone else first.

None of this is clever. It's the boring stuff, checked in order, every single time you ship. The list above you can run yourself. The last item, finding someone else to look, is the one people skip because it feels like admitting they might have missed something. That's exactly why it catches the most.

Related reading

Harbova is a security service for apps built with AI tools. Start with a free scan, and if it finds something serious, we can fix it and prove it is closed.