OWASP Top 10 without the jargon

Sooner or later someone tells you your app should be checked against the OWASP Top 10, and you nod. It sounds like a certification you failed to get. It is not. It is a list, kept by a nonprofit, of the ten kinds of mistakes that keep showing up in real applications, year after year, in every language and every stack.

That last part is the useful part. These are not exotic attacks. They are patterns, which is exactly why a list of ten can cover most of what goes wrong.

The three that show up most in apps built with AI

Hiding the button is not locking the door. This is the first item on the list and the one we find most often. Your app shows the admin menu only to admins, and everyone assumes that settled it. But the menu is the drawing, and the address behind it is the door. If the address still answers when a regular account asks, the app is checking the wrong side.

The second is configuration left the way it came. Rules never switched on, a test page still online, a debug screen that prints more than it should, an error message that names the database. Nothing here was written wrong. It was written for the first day and never revisited. The most common version of it in apps built with AI is the database key written into the page.

The third is trusting what someone typed. When text that a visitor typed reaches a place where instructions get carried out, the app cannot tell a name from an order. That is the whole idea behind injection, and it now has a modern cousin: text that reaches a language model instead of a database, which is someone giving orders to the AI inside your app.

The whole list, one line each

• Broken access control: someone reaches data or actions that were meant for someone else.
• Cryptographic failures: sensitive data stored or sent in a way that anyone who gets hold of it can read.
• Injection: text typed by a visitor ends up being treated as an instruction.
• Insecure design: the feature itself has no safe version, no matter how well it is coded.
• Security misconfiguration: defaults, leftovers and debug switches still on in production.
• Vulnerable components: a library with a known hole, still in your app because nobody updated it.
• Authentication failures: weak login, guessable codes, sessions that never really end.
• Software and data integrity failures: your app trusts an update or a package it has no way of verifying.
• Logging and monitoring failures: something happens and nothing anywhere records it.
• Server-side request forgery: your server is talked into fetching something on the attacker behalf.

The list gets revised every few years and the names shift a little between editions. The nature of what is on it does not.

None of these are clever. That is exactly why they keep working.

What this means for you

You do not have to memorize any of it. The reason the list matters to someone who builds by describing what they want is that it gives the vague worry a shape. "Is my app secure" has no answer. "Can a logged-out person open this address" has one, and you can test it yourself in thirty seconds.

That is also what a scan is doing when it runs against your app: walking a list like this one, from the outside, asking the specific questions instead of the vague one. What you do with the answers is the other half of the problem, and that half is why most security reports never turn into fixes.