OWASP Top 10 in Real Life: How Apps Actually Get Hacked

Quickstart

If you only have 60–90 minutes, do these in order. They catch the most common “we got hacked and don’t know how” incidents without needing a full security program.

Overview

The OWASP Top 10 is a standard awareness list of the most critical risks in web apps. “Top” doesn’t mean “most common bug in your codebase” — it means the patterns that repeatedly lead to real compromises: account takeover, data leakage, malicious updates, and outages that become security incidents.

Note: OWASP updates its categories over time. The names shift, but the underlying themes stay stable: authorization bugs, insecure defaults, dangerous trust in inputs and dependencies, and weak detection. This post focuses on how these risks show up in real systems — and what “good” looks like in code and operations.

Core concepts

Before we dive into the Top 10, align on a few concepts. These are the building blocks that turn “security advice” into repeatable engineering patterns.

Authentication vs authorization (and why teams mix them up)

Authentication answers “Who are you?” Authorization answers “What are you allowed to do?” Most real incidents happen when an app authenticates correctly — then authorizes incorrectly.

Trust boundaries: where “internal” becomes dangerous

A trust boundary is any place your app accepts input or assumptions from something you don’t fully control: browsers, mobile clients, third-party webhooks, background jobs, internal microservices, even your own CI system. The OWASP Top 10 repeatedly boils down to trusting the wrong boundary.

Secure-by-default beats perfect-by-policy

Security programs fail when every team must remember 50 rules. They succeed when the default templates are safe: secure headers, strict CORS, hardened cookie settings, dependency pinning, and logging hooks already present. Your future self will thank you.

Step-by-step

Here’s a practical way to use the OWASP Top 10 on a real application: run a lightweight audit that maps your app’s attack surface, then walk through each category with “what fails” and “what good looks like”.

Step 1 — Inventory your attack surface (30 minutes)

Step 2 — Walk the Top 10 with real-life scenarios

Below are the Top 10 categories as they show up in real apps: what typically happens, what attackers leverage, and how to fix the root cause.

A01 — Broken Access Control

Real-life scenario: A logged-in user can access another user’s document/order/invoice by requesting it with a different ID. This often happens after “moving fast” with a UI that hides buttons — but the API never enforces ownership.

/**
 * Express example: object-level authorization (tenant + ownership).
 * Pattern: load resource, then authorize based on server-trusted fields.
 */
import express from "express";

const app = express();

// Pretend auth middleware sets req.user = { id, orgId, role }
function requireAuth(req, res, next) {
  if (!req.user) return res.status(401).json({ error: "unauthorized" });
  next();
}

function canReadInvoice(user, invoice) {
  // Deny-by-default; allow only explicit rules.
  if (user.role === "admin" && user.orgId === invoice.orgId) return true;
  return user.orgId === invoice.orgId && user.id === invoice.ownerId;
}

app.get("/api/invoices/:invoiceId", requireAuth, async (req, res) => {
  const invoice = await db.invoices.findById(req.params.invoiceId);
  if (!invoice) return res.status(404).json({ error: "not found" });

  if (!canReadInvoice(req.user, invoice)) {
    // Log on the server (not shown): userId, orgId, invoiceId, outcome=denied
    return res.status(403).json({ error: "forbidden" });
  }

  res.json({ invoice });
});

A02 — Security Misconfiguration

Real-life scenario: An app ships with a permissive CORS config, verbose error pages, open debug endpoints, public storage buckets, or “temporary” admin routes. These aren’t exotic — they’re operational footguns.

A03 — Software Supply Chain Failures

Real-life scenario: A dependency is compromised upstream, or a CI workflow is edited to run untrusted code with powerful tokens. Your app “gets hacked” even though your application logic is fine — because the build system is the new perimeter.

# GitHub Actions example: reduce supply chain risk.
# - Pin actions to a commit SHA (immutable)
# - Use minimal permissions
# - Run dependency review on PRs
name: ci

on:
  pull_request:
  push:
    branches: [ "main" ]

permissions:
  contents: read

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11

      - name: Setup Node
        uses: actions/setup-node@1a4442e0c7b6a7fdc5c2ccda5c0c5d37a8e5cdb4
        with:
          node-version: "20"
          cache: "npm"

      - name: Install (locked)
        run: npm ci

      - name: Dependency review (PR only)
        if: github.event_name == 'pull_request'
        uses: actions/dependency-review-action@0ee6b24b0acb6c2f7c5bd1b7d83d6b8ad0e6d6f3

      - name: Test
        run: npm test

A04 — Cryptographic Failures

Real-life scenario: Sensitive data is stored or transmitted without the right protections. It might be passwords with weak hashing, tokens without expiry, secrets hardcoded in config, or “encryption” implemented incorrectly.

A05 — Injection

Real-life scenario: Untrusted input reaches a “sink” (database, template, command runner, query language) without a safe interface. Injection isn’t just SQL — it’s any place strings become “code.”

"""
Python example: parameterized queries + safe errors.
- Use bind parameters (never string-build queries from user input).
- Return generic error messages; log detailed context server-side.
"""
import logging
import psycopg

log = logging.getLogger("app")

def get_order_for_user(conn: psycopg.Connection, user_id: str, order_id: str) -> dict | None:
  # Object-level authorization belongs in the query as well (defense-in-depth).
  sql = """
    SELECT id, user_id, total_cents, status
    FROM orders
    WHERE id = %s AND user_id = %s
  """
  with conn.cursor() as cur:
    cur.execute(sql, (order_id, user_id))
    row = cur.fetchone()
    if not row:
      return None
    return {"id": row[0], "user_id": row[1], "total_cents": row[2], "status": row[3]}

def handle_request(conn, user_id, order_id):
  try:
    order = get_order_for_user(conn, user_id, order_id)
    if order is None:
      return 404, {"error": "not found"}
    return 200, {"order": order}
  except Exception as exc:
    # Log with structured context; avoid leaking internals to clients.
    log.exception("order_lookup_failed", extra={"user_id": user_id, "order_id": order_id})
    return 500, {"error": "internal error"}

A06 — Insecure Design

Real-life scenario: The code is “correct,” but the system’s rules are unsafe. Examples: unlimited password reset attempts, no abuse controls, no tenant isolation concept, or workflows where a low-privilege user can trigger high-impact actions indirectly.

A07 — Authentication Failures

Real-life scenario: Account takeover via weak login protections, unsafe password reset, missing MFA for admins, token reuse, or sessions that don’t expire.

A08 — Software or Data Integrity Failures

Real-life scenario: The app accepts data or updates that aren’t verified: unsigned webhooks, tampered files, insecure deserialization, untrusted update channels, or “trust me” admin imports.

A09 — Security Logging & Alerting Failures

Real-life scenario: An attacker tries dozens of auth flows, hits unusual endpoints, or probes tenant boundaries — and nobody sees it. Logging exists, but it’s unstructured, missing key events, or not tied to alerts.

A10 — Mishandling of Exceptional Conditions

Real-life scenario: When something goes wrong (timeouts, nulls, unexpected input, third-party failures), the app leaks details, fails open, retries in a loop, or crashes in ways that expose data or create an availability incident.

Step 3 — Turn findings into patterns (not a bug list)

The fastest way to improve security is to convert repeated problems into reusable patterns: one authorization helper, one secure config baseline, one logging policy, one dependency/CI policy.

Common mistakes

These are the “we didn’t think that mattered” mistakes that repeatedly show up in real incidents. Each has a simple fix you can standardize.

FAQ

Is the OWASP Top 10 a checklist for pen testing?

Not exactly. It’s primarily an awareness and prioritization list. You can use it to guide testing, but the highest leverage use is to build patterns and defaults so you stop re-introducing the same classes of bugs.

What’s the difference between “Broken Access Control” and “Authentication Failures”?

Authentication is proving identity (login, MFA, tokens). Access control is enforcing permissions after identity is known. In practice, apps often authenticate correctly and still leak data because authorization is missing or inconsistent.

How do I prioritize fixes when everything feels risky?

Start where breaches scale: (1) access control on data endpoints, (2) misconfiguration + secrets exposure, (3) supply chain + CI permissions, then (4) logging/alerting and safe error handling. These reduce both likelihood and blast radius quickly.

Do I need expensive tools to address the Top 10?

No. Good security is mostly about patterns: deny-by-default authorization, parameterized queries, pinned builds, secure configuration templates, and basic monitoring. Tools help, but they don’t replace the fundamentals.

What does “Software or Data Integrity Failures” mean in plain English?

It means you accepted something you shouldn’t trust. Unsigned webhooks, tampered files, unsafe imports, or unverified updates. The fix is verification: signatures, checksums, provenance, and strict validation.

How do I avoid leaking sensitive info in logs while still being able to debug?

Log events and identifiers, not raw secrets. Use structured logs with request IDs, user IDs, and resource IDs, redact tokens automatically, and move detailed payload inspection behind secure, temporary debugging workflows.

Cheatsheet

Keep this near your PR reviews. If your team consistently answers these items, you’ll eliminate most common web app compromises.

Wrap-up

The OWASP Top 10 becomes powerful when you treat it as engineering guidance, not a poster. The “real life” version is simple: enforce authorization consistently, remove insecure defaults, harden the supply chain, validate untrusted inputs, and build detection + safe failure into your system.

Related posts

• CSP Explained: Prevent XSS Without Breaking Your Site
• Threat Modeling in 45 Minutes: A Lightweight Template
• Passkeys, MFA, Sessions: Modern Authentication Done Right
• API Security Checklist: Auth, Rate Limits, and Abuse Cases
• DevSecOps Basics: Add Security to CI/CD Without Chaos
• Dependency Attacks: How One Package Can Burn Your App