Four gaps a fast-shipped AI app usually leaves open

Building an AI app is quicker than it has ever been. A small team, or one founder with good tools, can go from idea to paying users in weeks. The product part gets the attention, and it should.

The plumbing around the product is where speed tends to leave holes. None of the four below needs a security team to close. Each one is an afternoon for one developer, and each one is easy to check today.

1. The website is protected. The app is not.

Most teams put their marketing site behind a service like Cloudflare, which filters bad traffic and absorbs floods of requests. The app itself, the server with the customer data, often sits on its own address that answers anyone who finds it. Cloudflare only protects traffic that goes through Cloudflare, so a visitor who goes straight to the server skips all of it.

How to close it: put the app's domain behind the same protection, set the server to accept traffic only from the protection service's addresses, and move the server to a new address that has never been public.

Check it: look up your app's domain. If it points straight at your own server rather than at your protection service, it's open.

2. Your app's public code lists your private routes

Web apps ship their front-end code to every visitor's browser. Build tools often bundle every route the app knows about into that code, including admin pages and internal API paths. Anyone can open the file and read the list. It doesn't hand over access by itself, but it gives an attacker a map.

How to close it: strip internal and admin routes from the production build, and serve the admin screens as a separate bundle that only signed-in admins download.

Check it: open your site, view the main script file, and search it for "admin".

3. Password reset has no limit

A reset form that accepts unlimited requests lets anyone flood a customer's inbox with reset emails. If it answers "no account with that email" differently from "email sent", it also tells strangers which email addresses are your customers.

How to close it: limit requests per network address and per email address, add a CAPTCHA after a few tries, and give the same reply whether the account exists or not.

Check it: submit the reset form ten times in a row for your own email. If all ten emails arrive, there's no limit.

4. The same gap on login and one-time codes

Login forms and one-time codes (the six digits sent by text or email) have the same weakness. With no limit, a short code can be guessed by brute force.

How to close it: lock the attempt after five wrong guesses, slow down repeated tries from the same address, and expire codes quickly.

Check it: enter a wrong code six times. If the sixth is still accepted for checking, there's no lockout.

The demo

We reproduced all four on a small demo app of our own, running only on our machine, and then closed each one. The video shows the gap, the fix, and the result side by side.

Watch the 70-second demo

Why we're writing this

Deemwar builds and runs AI agents, and a person approves anything that matters. Checks like these are part of what a careful development team does by habit. If you've shipped fast and want a second pair of eyes on your setup, tell us what you're running.