The OWASP Top 10, Explained

The list every attacker has already read

You ship a feature. It works in the demo, the tests are green, the PR is approved. Three weeks later someone changes a number in a URL and reads another customer's invoices. Nothing crashed. No alarm fired. The code did exactly what you wrote, you just never told it who was allowed to ask.

Almost every breach you read about traces back to a small, named, well-understood mistake. The OWASP Top 10 is the industry's shared list of those mistakes, the ten categories of web application risk that show up most often and hurt the most. It is maintained by the Open Worldwide Application Security Project, a nonprofit, and it is the single best starting map for anyone who builds or operates web software.

We will walk all ten: what each one is, a concrete example, and how to prevent it. Then we will turn the list into a practical routine you can actually run.

One sentence, then a picture

The OWASP Top 10 is not a list of bugs, it is a list of the ten ways trust gets misplaced in a web application.

Here is the analogy. Think of your application as a building. Most of the Top 10 are not exotic break-ins, they are the unlocked side door, the master key that opens every room, the contractor you let in without checking ID, and the security camera that was never plugged in.

Before the list, look at where these risks actually land. A web app is not one thing, it is a chain of trust boundaries, and each risk hits a specific link.

The happy path is the straight line: browser to API to database. The two dashed branches, your dependencies and your config, are the ones teams forget, and they are where two whole categories of the Top 10 live.

The OWASP Top 10 at a glance

This is the centerpiece. Read it once top to bottom for the shape of the landscape, then keep it open as a reference. The order mirrors the 2021 list, which is ranked by real-world prevalence and impact.

A few of these, made concrete

Tables are great for scanning, but risks click when you see them happen. Three quick ones.

Broken Access Control (A01)

Your invoice page is at /invoices/1043. A curious user changes it to /invoices/1042 and sees someone else's bill. The server happily returned it because the only check was "are you logged in?", never "is this yours?". This is called an insecure direct object reference (IDOR), and it is the most common breach you will ever cause by accident.

Injection (A03)

A login form builds a query like SELECT * FROM users WHERE name = '" + input + "'. The attacker types ' OR '1'='1 as the username, and suddenly the WHERE clause is always true. They are in. The fix is mechanical: stop building queries by gluing strings together. We cover this in depth in Preventing Injection Attacks (SQLi & XSS).

Server-Side Request Forgery (A10)

Your app has an "import image from URL" feature. An attacker submits http://169.254.169.254/latest/meta-data/, the cloud metadata endpoint, and your server, which can reach it, fetches and returns your cloud credentials. The user could never reach that address; your server could, and you let it become a proxy.

How to use the Top 10 in practice

A list you read once and forget changes nothing. Here is how to turn it into a routine that actually catches issues, on a feature, a service, or a whole codebase.

1. 1

   Map your attack surface

   Sketch the layers from the diagram above for your own app: client, API, database, dependencies, config. You can't defend trust boundaries you haven't drawn.

2. 2

   Walk the data flow

   Follow one real request end to end. At every hop ask: where does untrusted input enter, and where do I trust it without checking? Those points are your candidates.

3. 3

   Score each risk against your app

   Go down the Top 10 row by row and ask "could this happen here?" Mark each Yes / No / Not sure. "Not sure" is the answer that needs follow-up.

4. 4

   Fix highest-impact first

   Start with A01 access control and A03 injection, they are common and devastating. Don't polish logging while the side door is unlocked.

5. 5

   Automate the repeatable parts

   Add a dependency scanner (A06) and secret/config checks (A05) to CI so regressions get caught without a human remembering to look.

6. 6

   Re-run it on every meaningful change

   New endpoint, new dependency, new integration? Re-walk the relevant rows. Security is a habit, not a one-time audit.

Fixing a real one: a server-side ownership check

Let's fix the A01 example from earlier. The vulnerable version checks that you are logged in, then trusts the ID in the URL. The fixed version checks that the record actually belongs to you, on the server, where the user can't tamper with it.

# VULNERABLE: any logged-in user can read any invoice
@app.get("/invoices/<invoice_id>")
@login_required
def get_invoice(invoice_id):
    invoice = db.invoices.find_by_id(invoice_id)
    return jsonify(invoice)  # never checked who owns it


# FIXED: deny by default, enforce ownership server-side
@app.get("/invoices/<invoice_id>")
@login_required
def get_invoice(invoice_id):
    invoice = db.invoices.find_by_id(invoice_id)

    # 1. Does it exist at all?
    if invoice is None:
        abort(404)

    # 2. Does it belong to the caller? (the check that matters)
    if invoice.owner_id != current_user.id:
        # 404, not 403, don't even confirm the record exists
        abort(404)

    return jsonify(invoice)

Two things to notice. First, the ownership check uses current_user.id from the verified session, never an ID sent by the client. Second, when the record isn't yours we return 404, not 403: a 403 quietly confirms the invoice exists, which leaks information. Deny by default, and reveal nothing.

Common mistakes that cost hours

1. Checking permissions in the UI only. Hiding a button is not security, the API behind it must enforce the rule. Attackers call the API directly.
2. Trusting an ID from the request to decide ownership. If the client sends user_id=42, an attacker sends user_id=7. Derive identity from the verified session, never the payload.
3. Treating the Top 10 as a one-time audit. It is a recurring lens. A new endpoint added next week reintroduces A01 if nobody re-checks.
4. Rolling your own crypto or auth. Hashing passwords with SHA-256, hand-writing JWT validation, inventing a token scheme, use vetted libraries (bcrypt/argon2, a maintained auth framework) instead.
5. Forgetting dependencies and config (A05, A06). Teams obsess over their own code and ship a 3-year-old library with a known CVE or a publicly readable storage bucket.
6. Logging the wrong things. Either nothing useful (so you're blind during an incident) or too much, dumping passwords and tokens into logs, which becomes a breach of its own.

Takeaways

Where to go next

The Top 10 is the map; the next step is going deep on the territory. Start with the categories you marked "Yes" or "Not sure" in the practice walkthrough.

• Preventing Injection Attacks (SQLi & XSS), A03 in depth, with the exact query patterns that are safe and the ones that aren't.
• Secure API Design, how to build access control, input validation, and rate limiting in from the start rather than bolting them on.
• Authentication vs Authorization, the distinction underneath A01 and A07: who you are versus what you're allowed to do.
• Practice the surrounding skills on the DevOps Engineer path, where security threads through pipelines, config, and infrastructure.

Read the official OWASP Top 10 once for the canonical detail, but you now have the mental model to make it land. Pick one risk, run the six-step routine against something you own this week, and fix what you find.