OWASP Top 10 Checklist: Review and Test Plan for Your Own App

A freelance developer has just finished an invoice-sharing app for a client. It works, the tests are green, and then the client asks one sentence: "Is it secure?" That question has no yes or no answer, but it has a good response: "Here is what I checked, here is how, and here is what I would fix first." This lesson builds that response. The OWASP Top 10 (current edition) is not a compliance standard, but it is an excellent skeleton for a structured review of an app you own.

Step one: describe the app on half a page

A checklist is only useful when applied to something specific. Before reviewing, write down the data the app holds, who the user roles are, which endpoints accept input, which external services it calls and where it runs. Anything left out of this description will be left out of the review. A few minutes spent here prevents the most common review failure, which is carefully checking the parts you already remembered.

Step two: one checklist, grouped by theme

ACCESS CONTROL
  [ ] Every endpoint that takes an id checks ownership or role on the server.
  [ ] Admin routes are denied by default and tested with a normal user.
  [ ] Role and permission fields cannot be set from request bodies.

INJECTION AND OUTPUT
  [ ] All SQL uses parameters or a query builder; no string-built queries.
  [ ] No user input reaches a shell, template engine or file path unchecked.
  [ ] User-supplied text is encoded for the page context where it appears.

AUTHENTICATION AND SESSIONS
  [ ] Login attempts are throttled; admin accounts require MFA.
  [ ] Passwords use a slow salted hash; reset tokens are random and expire.
  [ ] Session cookies are HttpOnly, Secure and SameSite; new id after login.

CRYPTOGRAPHY AND DATA
  [ ] HTTPS everywhere; no secrets in source control; keys rotated.
  [ ] Sensitive fields are encrypted or not stored at all.
  [ ] Backups are protected as strongly as production data.

CONFIGURATION
  [ ] Debug off in production; generic error pages; no default accounts.
  [ ] Security headers set; storage buckets and admin panels not public.
  [ ] Staging uses synthetic data.

COMPONENTS
  [ ] Dependency scan runs in CI; owner named for updates.
  [ ] Unused packages and endpoints removed.

DESIGN
  [ ] Abuse cases written for each risky feature (limits, resets, coupons).
  [ ] Critical state changes are atomic and enforced by the database.

OUTBOUND REQUESTS (SSRF)
  [ ] Any feature that fetches a user-supplied URL has scheme and
      destination limits, timeouts and redirect handling.

LOGGING AND RESPONSE
  [ ] Logins, denials and admin actions are logged without secrets.
  [ ] At least three alerts exist and have been tested.
  [ ] There is a one-page incident plan and a tested backup restore.

Each line is a yes or no question. A "no" or "I do not know" becomes a ticket. Resist the urge to add fifty more items: a short list that gets completed beats a long one that gets skimmed.

Step three: automate the access-control matrix

Of everything on the list, access control is the area where automated tests pay back most, because the failure is invisible to a single-user tester. The idea is a matrix: rows are users and roles, columns are resources, cells say whether access is expected. A test walks the matrix and fails on any difference. The version below uses SQLite so you can run it, but the same table can drive HTTP calls against a test server.

import sqlite3

db = sqlite3.connect(":memory:")
db.executescript("""
CREATE TABLE invoices (id INTEGER PRIMARY KEY, owner TEXT, total INTEGER);
INSERT INTO invoices VALUES (1, 'asha', 120), (2, 'bruno', 80);
""")

def get_invoice(user: str, role: str, invoice_id: int):
    if role == "auditor":
        return db.execute("SELECT id, owner, total FROM invoices WHERE id = ?", (invoice_id,)).fetchone()
    return db.execute(
        "SELECT id, owner, total FROM invoices WHERE id = ? AND owner = ?", (invoice_id, user)
    ).fetchone()

# (user, role, invoice id, should the caller see it?)
MATRIX = [
    ("asha",  "customer", 1, True),
    ("asha",  "customer", 2, False),
    ("bruno", "customer", 1, False),
    ("carol", "auditor",  1, True),
    ("carol", "auditor",  2, True),
]

failures = 0
for user, role, invoice_id, expected in MATRIX:
    allowed = get_invoice(user, role, invoice_id) is not None
    status = "ok  " if allowed == expected else "FAIL"
    failures += status == "FAIL"
    print(f"{status} {user}/{role} -> invoice {invoice_id}: visible={allowed}")

print("failures:", failures)

ok   asha/customer -> invoice 1: visible=True
ok   asha/customer -> invoice 2: visible=False
ok   bruno/customer -> invoice 1: visible=False
ok   carol/auditor -> invoice 1: visible=True
ok   carol/auditor -> invoice 2: visible=True
failures: 0

Put the matrix next to your normal tests and run it in CI. When someone adds a new endpoint or role, adding a row becomes part of the definition of done. The negative rows (expected False) are the valuable ones, since they are the cases a happy-path test never touches.

Step four: decide where each check runs

Step five: prioritise by exposure and impact

Not every unchecked box deserves a sprint. Sort findings by two questions: how easily can it be reached (an anonymous internet user, a logged-in user, an admin only) and what is lost if it is (every customer's data, one user's profile, a cosmetic page). A missing ownership check on an endpoint that returns invoices outranks a missing referrer header every time. Write each finding as a one-line sentence with a proposed fix and an owner, and handle the top three before anything else. Tie authentication-related items back to the way your app issues tokens, covered in JWT authentication.

Common mistakes

• Running a scanner and calling it a review. Symptom: a clean report on an app where user A can open user B's invoice, because scanners cannot know your business rules. Fix: pair tools with the access matrix and manual checks.
• Testing with one admin account. Symptom: every test passes, and the first normal customer to explore finds a data leak. Fix: at least two normal users and one limited role in every test.
• Treating the checklist as a one-off. Symptom: it was clean at launch and stale six months later. Fix: run it per release or at least quarterly.
• Fixing symptoms in order of discovery. Symptom: low-risk header findings fixed while the unauthenticated endpoint stays open. Fix: sort by exposure and impact.
• Skipping the report-back. Symptom: the client or manager hears nothing and assumes either everything or nothing is fine. Fix: a one-page summary of what was checked, what was found and what is next.

How this shows up in real projects and interviews

Teams that do this well keep the checklist in the repository, wire the cheap parts into CI and review the rest at release time. In interviews, being able to describe a concrete process ("I keep an access matrix as a test and a short checklist per release") reads as far more credible than reciting a list of categories from memory. If you want to turn this skill into a career move, look at security-related roles and the skills employers ask for, and practise explaining your process out loud with the tips in thinking out loud in interviews.