The OWASP Top 10, explained for founders (with real examples)

You shipped something. It works. People are signing up. And somewhere in the back of your head is the nagging thought that you have no idea whether a stranger can read your other users' data. That's the right thing to worry about, and the OWASP Top 10 is the closest thing the industry has to a checklist for it.

The OWASP Top 10 is a list, maintained by the Open Worldwide Application Security Project, of the ten most common and damaging categories of web application security risk. It is not academic. Each category represents the kinds of holes attackers actually walk through, ranked by how often they show up and how badly they hurt. You don't need to memorize it. You need to understand it well enough to know what to look for in your own app before someone else looks for you.

Broken Access Control

This is number one for a reason: it's the most common serious flaw, and it's the easiest to introduce by accident. Broken access control means a user can do or see something they shouldn't. The classic version is IDOR, an Insecure Direct Object Reference, where your app loads a record by its ID without checking who's asking.

Real example: your invoice page is at /invoices/1043. A curious user changes it to /invoices/1042 and reads someone else's invoice. You checked that they were logged in, but never that the invoice belonged to them. The one thing to do: for every request that touches data, verify both that the user is authenticated and that they own or are allowed to touch that specific resource. We go deep on this pattern in IDOR, explained in depth, because it's the one that bites founders most often.

Cryptographic Failures

This used to be called "Sensitive Data Exposure," which describes the damage better. It covers data that should be protected but isn't: passwords stored in plain text, traffic served over HTTP instead of HTTPS, secrets sitting in a database column anyone with read access can see.

Real example: a startup stores password reset tokens in the database unhashed, and a separate read-only bug exposes them. Now attackers can reset any account. The one thing to do: never store passwords as anything but a strong salted hash (bcrypt, argon2), force HTTPS everywhere, and treat any field holding tokens, keys, or personal data as something that must be encrypted at rest.

Injection

Injection happens when untrusted input gets interpreted as a command. SQL injection is the famous one: a login form where typing a crafted string into the username field lets an attacker rewrite your database query and dump every user. But injection also covers command injection, LDAP, and others.

Real example: you build a query by gluing strings together, so name = ' + userInput + ' becomes a way for an attacker to comment out the rest of your query and run their own. The one thing to do: use parameterized queries or an ORM that parameterizes for you, and never concatenate user input into a query, a shell command, or anything an interpreter will execute.

Insecure Design

This category is about flaws baked into how the system was conceived, not how it was coded. You can implement a bad idea perfectly. No amount of clean code fixes a feature that was never safe to build the way you built it.

Real example: a password reset flow that emails a 4-digit code with no rate limit. The code is implemented correctly. The design is the problem: 10,000 guesses is nothing, and an attacker brute-forces it in seconds. The one thing to do: before building anything that touches accounts, money, or sensitive data, ask "how would I abuse this?" and design the limits, checks, and failure modes in from the start.

Security Misconfiguration

Most apps are insecure not because of exotic bugs but because something was left on, open, or default. Debug mode in production, default admin credentials, an S3 bucket set to public, verbose error pages that leak stack traces and file paths.

Real example: a framework ships with detailed error pages enabled, an exception fires in production, and the page hands an attacker your database structure and library versions. The one thing to do: ship with debug off, default accounts removed, error messages generic, storage buckets private by default, and only the ports and services you actually need exposed.

Vulnerable and Outdated Components

Your app is mostly other people's code. Every dependency you pull in is a door, and when a known vulnerability is published for one of them, attackers scan the entire internet for apps still running the old version. The flaw isn't yours, but the breach will be.

Real example: you pinned a library version eighteen months ago, a critical CVE was disclosed for it last spring, and you never updated. Automated scanners find it before you do. The one thing to do: keep a dependency manifest, run an automated audit (npm audit, pip-audit, or equivalent) regularly, and update anything with a known high-severity issue before launch.

Identification and Authentication Failures

This is everything that goes wrong with proving who someone is: weak password rules, no protection against brute force, session tokens that never expire, login that leaks whether an email exists.

Real example: an attacker takes a list of leaked email/password pairs from another breach and replays them against your login, with no rate limiting and no second factor to stop them. Thousands of accounts fall. The one thing to do: rate-limit and lock out on repeated failures, offer (or require) multi-factor authentication, expire sessions sensibly, and never reveal whether a given account exists.

Software and Data Integrity Failures

This covers trusting code or data that you can't verify hasn't been tampered with: auto-updates without signature checks, build pipelines that pull unverified scripts, deserializing untrusted data into live objects.

Real example: your CI pipeline runs a third-party script fetched over an unpinned URL during every build, and the day that script is compromised, your build ships malware to your users. The one thing to do: verify integrity of what you pull into builds and updates, pin and check dependencies, and never deserialize data from a source you don't control.

Security Logging and Monitoring Failures

This one is quiet, which is the problem. If you don't log security-relevant events and nobody watches them, a breach can run for months before you notice, usually because a customer or a journalist tells you first.

Real example: an attacker is brute-forcing logins for weeks, but you log nothing, alert on nothing, and find out only when accounts start getting drained. The one thing to do: log authentication events, access-control failures, and server errors; make sure the logs survive a crash; and set at least a basic alert on the patterns that mean trouble.

Server-Side Request Forgery (SSRF)

SSRF happens when your server fetches a URL that a user controls, and the attacker points it somewhere it shouldn't go: your internal network, a cloud metadata endpoint, a service that should never be reachable from outside.

Real example: a "fetch image from URL" feature lets an attacker submit your cloud provider's internal metadata address and pull back credentials that grant access to your whole account. The one thing to do: validate and allowlist any URL your server fetches on a user's behalf, block requests to internal and private address ranges, and never blindly follow redirects.

How to actually check your app before launch

Reading the list is step one. The harder part is finding out which of these ten apply to your specific app, in your specific code, before you put it in front of the public. A few ways to do that, roughly in order of effort:

• Read your own access-control logic. For every endpoint that returns user data, confirm it checks ownership, not just login.
• Run a dependency audit and clear the high-severity findings.
• Check your config: debug off, secrets out of code, storage locked down, error pages generic.
• Run an actual security scan that tries these attacks against your running app, the way an attacker would. There's a full walkthrough in how to pentest your web app before launch.

That last step is where most founders stall, because traditional pentesting means a €15–20k engagement and weeks of waiting that an early-stage startup can't justify. Kalit Pentest runs an autonomous, authorized, non-destructive scan against your app with around a dozen specialist agents working in parallel, from reconnaissance through safe exploitation, and hands you a report where every finding has a CVSS severity, reproducible evidence, and a concrete fix. It maps directly onto the categories above, so you find out in minutes which of the Top 10 actually apply to you.

To recap, here's the OWASP Top 10 in founder terms:

1. Broken Access Control — users reaching data that isn't theirs (including IDOR).
2. Cryptographic Failures — sensitive data left unprotected in transit or at rest.
3. Injection — untrusted input executed as a command, including SQL injection.
4. Insecure Design — a feature that was never safe to build the way it was built.
5. Security Misconfiguration — something left default, open, or verbose.
6. Vulnerable and Outdated Components — known holes in the libraries you depend on.
7. Identification and Authentication Failures — weak proof of who someone is.
8. Software and Data Integrity Failures — trusting code or data you can't verify.
9. Security Logging and Monitoring Failures — breaches running unseen.
10. Server-Side Request Forgery — your server tricked into fetching the wrong thing.

You don't have to become a security engineer to ship safely. You have to know these ten shapes well enough to spot them, and to check honestly whether your app has any of them before launch day.