This guide is the short, honest version of what I wish someone had handed me years earlier. It is not a checklist that makes you secure. It is a map of where the holes usually are, so you can stop being surprised by them. If you write code, this is your field guide. If you hire people who write code, this is enough to ask them the right questions.

The good news: someone already made the list

You do not have to discover these dangers yourself, one painful incident at a time. A group called OWASP already wrote them down.

OWASP stands for the Open Worldwide Application Security Project. It is a nonprofit, community-run effort, and everything it produces is free. It exists because a lot of practitioners, the same kind of people who learned the hard way, decided to pool what they knew so the next person would not have to bleed for it. Their most famous publication is the OWASP Top 10: a ranked list of the ten most critical risks in web applications, rebuilt every few years from real-world data across hundreds of organizations. The current edition came out in 2025.

I promote OWASP every chance I get, and not because anyone pays me to. I promote it because it is the closest thing our field has to a shared, honest warning label, and it costs nothing to read.

A free tool built by someone who needed it

The same spirit runs through the tools OWASP shepherds. The one I point people to first is ZAP, the Zed Attack Proxy. It is a free, open-source security scanner that sits between your browser and your web app and shows you what is actually happening underneath, including the weaknesses an attacker would probe for.

What I love about ZAP is its origin, because it is this whole guide in one story. Simon Bennetts was a working developer, not a security specialist. In 2009 he built a security-critical online service for a large company, planned the security, felt good about it, and brought in penetration testers a couple of weeks before launch to confirm he’d done it right. Within an hour, one of them was logged into the admin console using Simon’s own credentials. They hadn’t even needed a hole in his app; they’d cracked the company’s single sign-on. As he tells it on the Stack Overflow podcast, that was the moment it landed: “I’m pretty good at developing. I can make sure things work, they’re functional, they scale, they’re maintainable. I obviously can’t make them secure, so let’s learn a bit about security.”

He went looking and found the OWASP Top Ten, which he had never heard of (and which, he points out, plenty of developers still haven’t), and read it cover to cover. He also found something that bothered him: in 2009 there were no maintained open-source web security tools. None. So he forked an old one, wrote the rest in Java, and released it, at first anonymously, because he was afraid of being laughed at. OWASP adopted it, and ZAP grew into the most widely used web app scanner in the world. A developer who got caught out, decided to learn, and built the tool he wished he’d had. That is exactly how I came to this too, and it is why awareness is the thing I keep pointing at.

You do not need to be a security expert to run ZAP against your own site and learn something. That is the point.

The OWASP Top 10, in plain language

Here is the 2025 list, each item in one breath, with a concrete example. You will recognize some of these from the quiz. Don’t try to memorize them. Just let them make you a little more suspicious of your own code.

1. Broken access control

The most common flaw, by a wide margin: people can reach data or actions they should not be allowed to. The classic example is changing the number in a web address, /invoice/1043 to /invoice/1044, and seeing someone else’s invoice. The 2025 list also folds in server-side request forgery (tricking the server into making requests on an attacker’s behalf), because at root it is the same problem: something reaching what it shouldn’t.

2. Security misconfiguration

The software is fine; the way it was set up is not. A database left open to the internet with the default password, an admin panel reachable by anyone, detailed error pages that hand an attacker a map of your system. This one jumped up the list in 2025, because so much breaks not from clever attacks but from a setting nobody changed.

3. Software supply chain failures

Your app is mostly other people’s code: the libraries and packages you installed. When one of them has a known flaw, or worse, gets tampered with before it reaches you, that weakness is now yours. The example everyone fears is a popular package quietly updated with malicious code that ships straight into thousands of apps. This is a new top-level category in 2025, and it absorbed the older “vulnerable and outdated components” risk. The habit it asks of you: know what you depend on, keep it updated, and watch for advisories.

4. Cryptographic failures

Sensitive data that should be scrambled either isn’t, or is scrambled badly. Passwords stored in plain text, credit card numbers sent without encryption, a “secure” cookie that anyone can read. A common real version: storing passwords as a fast, unsalted hash like MD5, which falls in seconds once a database leaks. Use a slow, salted algorithm built for passwords (bcrypt, scrypt, or Argon2) instead.

5. Injection

Untrusted input gets treated as a command. The best-known form is SQL injection, where text typed into a form is run against your database. Type '; DROP TABLE users; -- into a field that isn’t protected, and you can delete the table. The dependable fix is parameterized queries (also called prepared statements), which keep user input as data and never as executable code. Cross-site scripting (XSS), where input is rendered into a page and the victim’s browser runs it as script, lives in this family too; the fix there is to escape output and add a Content Security Policy.

6. Insecure design

Some flaws aren’t bugs in the code; they’re holes in the plan. A password reset flow that lets anyone guess their way in, a checkout that trusts the price sent from the browser. You cannot patch your way out of a design that was never safe to begin with. The lesson: think about how a feature could be abused while you’re designing it, not after.

7. Authentication failures

Weak handling of who someone is. Letting people set “123456” as a password, no limit on login attempts so attackers can guess endlessly, session tokens that never expire or are easy to steal. If logging in is the lock on your front door, this is the category about whether the lock actually works.

8. Software or data integrity failures

Trusting code or data that you cannot verify wasn’t changed on its way to you. Auto-updating from a source you don’t control, running a build pipeline that anyone can slip code into, accepting serialized data and acting on it without checking. The question behind this one: can you prove that what’s running is what you intended to run?

9. Security logging and alerting failures

When something goes wrong, can you even tell? Many breaches go undetected for months simply because nothing was recorded and no one was alerted. If your app keeps no useful logs, or logs everything and watches none of it, an attacker can take their time. Log the events that matter, and make sure a human or system actually notices.

10. Mishandling of exceptional conditions

New in 2025: what your app does when something unexpected happens. An error that leaks internal details, a failure that accidentally leaves a door open, a “this should never happen” case that was never handled and so does something dangerous when it does. Handle the weird cases on purpose, because attackers go looking for exactly the situations you didn’t plan for.

The one habit underneath all ten

If you read that list and felt a little exposed, good. That feeling is the tool. Every one of these risks gets dramatically smaller the moment you know it exists, because then you design and review with it in mind. The teams I’ve watched get good at this did not buy their way there. They built the habit of asking, for every feature, “how could this be turned against the people using it?” and then checking.

A few concrete starting points, in plain terms:

• Keep user input on a short leash. Treat everything a user sends as untrusted. Parameterized queries for the database, escaped output for the page.
• Check permissions on every request, on the server. Never assume that because the button is hidden, the action is protected.
• Store secrets properly. Salted, slow password hashing. Encryption for sensitive data in transit and at rest.
• Know your ingredients. Keep a list of your dependencies, keep them updated, and watch for advisories.
• Watch and log. Record the events that matter and make sure someone or something is actually paying attention.
• Run ZAP against your own site. Let a free tool show you what you can’t see by reading the code.

None of this requires you to become a security specialist overnight. It requires you to stop being surprised. That is what awareness buys you, and it is why I send people to OWASP and ZAP before I send them anywhere else.