DEV Community

Cover image for I break into apps for a living. AI just made my job easier.
Ksatria Bintang Samudra
Ksatria Bintang Samudra

Posted on

I break into apps for a living. AI just made my job easier.

Here is an uncomfortable truth from the other side of the keyboard.

I started in security, penetration testing and bug hunting, before I became an AI-native full-stack engineer. So I have spent years thinking like an attacker. And lately, breaking into things has gotten easier.

Not because defenders got lazy. Because everyone started shipping code they never read.

The golden age of "it works, ship it"

AI can scaffold a working app in minutes. That is genuinely amazing, I use it every single day. But "it runs" and "it is safe" are two completely different sentences. AI is very good at the first one and completely indifferent to the second.

The model's job is to make the demo work. Your job, the part nobody can outsource, is to ask one question: what happens when someone malicious shows up?

In most AI-built apps I have looked at, nobody asked.

The same five holes, over and over

I am not going to hand attackers a how-to. But here is the pattern I keep seeing. If you ship web apps, you have probably done at least one of these this month:

1. Secrets in the client. API keys and tokens sitting right there in the frontend bundle or a committed .env. The model happily wired it up. It "works." It is also a free skeleton key for anyone who opens DevTools.

2. Authorization that is not. Authentication asks "who are you?" Authorization asks "are you allowed to do this?" AI nails the login screen and forgets the second question. So user A changes an ID in the URL and reads user B's data. Every time.

3. Trusting the client. Price calculated in the browser. Validation only on the frontend. "isAdmin" sent from the client and believed. The browser is the attacker's playground. Nothing that comes from it is a fact.

4. No rate limiting. Login, password reset, that expensive AI endpoint you pay per call for, all wide open to be hammered a thousand times a second. Your demo survives one user. It does not survive one bored person with a script.

5. Loud errors. Full stack traces, database messages, internal paths, shipped straight to the user. You just handed the attacker a map.

A system being probed on a monitor

This is not an anti-AI rant

Read me right. I am as AI-native as they come. I pair with AI to ship faster than a whole team. The tool is incredible.

But speed is a loaded gun. AI removed the friction that used to force you to slow down and think. That friction was doing a job. Now you have to do that job on purpose.

So do it on purpose:

  • Treat every input as hostile.
  • Check authorization on the server, for every single action.
  • Keep secrets on the server, always.
  • Rate-limit anything that costs money or guards a door.
  • Say less in your errors.

None of this is hard. It is just not automatic anymore. And "not automatic" is exactly where attackers live.

The part that should keep you up at night

The scariest apps I have seen were not built by beginners. They were built by smart people moving fast, who trusted the output because it looked clean. Clean code and safe code look identical, right up until the moment they do not.

So here is the one question I ask before anything I build goes live:

If I handed this app to someone who wanted to hurt me, what is the first thing they would try, and would it work?

If you do not know the answer, you do not have an app. You have an incident waiting for a date.

Ship fast. Just do not ship blind.


I am Ksatria Bintang Samudra, an AI-native full-stack engineer with a penetration-testing background, open to remote work worldwide. More of what I build at ksatriabintangsamudra.com.

Top comments (0)