The OWASP Top 10 explained

The OWASP Top 10 is a short list of the most critical risks to web applications, published by the Open Worldwide Application Security Project (OWASP), a non-profit community. It is built from real vulnerability data and expert input, and it is updated every few years. It is the most common starting point for secure coding, audits and security interview questions.

This lesson walks through the current edition, OWASP Top 10:2025, with a plain-English meaning, a Brew & Bean example and the main defence for each item. The detailed fixes for the biggest ones have their own lessons in this track.

If you know the 2021 list: Broken Access Control stayed at number one; Security Misconfiguration moved up; the old "Vulnerable and Outdated Components" grew into the wider Software Supply Chain Failures; Injection moved down; and Mishandling of Exceptional Conditions is a new category. Server-Side Request Forgery (SSRF), a separate item in 2021, is now folded into Broken Access Control. Check the official OWASP site for the exact wording.

The app does not properly enforce what each user may do. Example: a logged-in customer changes /orders/41 to /orders/42 in the URL and sees someone else's order and phone number. Or an ordinary user calls the staff-only status endpoint.

Defence: deny by default; check permission on the server for every request; check that the user owns the object. The full tutorial is *Authorisation and broken access control*.

Safe software with unsafe settings. Examples: debug mode left on in production, default admin passwords, a database open to the whole internet, a storage bucket that is public, missing security headers, detailed error pages that show stack traces.

Defence: a repeatable, minimal configuration; turn off what you do not use; separate settings for development and production; review settings in code review; scan configuration with tools (see *Security testing tools* in this track).

Your app is mostly other people's code: npm and PyPI packages, base Docker images, build tools, CI services. If any link is compromised or outdated, your app is affected. Examples: an old library with a known bug; a malicious package with a name close to a real one; a build pipeline that anyone can change.

Defence: know your dependencies, update them, pin versions with a lockfile, scan them, and protect your build pipeline. See *Dependencies and supply-chain security*.

Sensitive data is exposed because encryption is missing or wrong. Examples: sending data over plain HTTP, storing passwords with a fast hash like MD5, hard-coding an encryption key in the source, using your own invented algorithm.

Defence: HTTPS everywhere, a proper password hashing function, well-tested libraries, protect and rotate keys, and do not collect data you do not need. See *Cryptography basics*.

The app builds a command or query by gluing in user input, so the input can change the meaning. Example: a search box that puts text straight into an SQL statement, so typing SQL syntax changes the query. Cross-site scripting (XSS), where user text becomes script in another user's browser, belongs here too.

Defence: keep data and commands separate with parameterised queries; encode output; validate input. See *Injection attacks: SQL, command and XSS*.

A flaw in the design, not in the code. A perfect implementation of a bad design is still insecure. Example: an order cancellation feature that refunds automatically with no limits, so a script could abuse it; or a password reset that asks for easily found information.

Defence: threat model early, write abuse cases ("how could someone misuse this?") alongside use cases, and add limits. See *The security mindset and threat modelling*.

Weak proof of who a user is. Examples: allowing the password 123456, no protection against endless password guessing, sessions that never expire, login tokens that are easy to steal, no second factor for sensitive accounts.

Defence: strong password hashing, rate limiting, multi-factor authentication, secure session handling and not building your own login system when a trusted library or identity provider will do. See *Passwords, authentication and MFA done right*.

The app assumes code or data is genuine without checking. Examples: loading a script from a third-party site without verifying it; installing updates that are not signed; trusting serialised data from the client, such as a cookie that says role=admin with no signature; a CI pipeline that deploys unreviewed code.

Defence: verify signatures and checksums, sign data you hand to clients, use Subresource Integrity for scripts from a CDN, and review changes before they deploy.

When something bad happens, you cannot see it or respond. Examples: failed logins are not logged; logs exist but nobody looks at them; no alert when 500 failed logins occur in a minute; logs that accidentally contain passwords.

Defence: log security events (logins, failures, permission denials, status changes) with time, user and source; keep logs safe; alert on unusual patterns; never log secrets or full card or password data.

Programs fail in unexpected ways: bad input, a database timeout, a missing file, running out of memory. If these cases are handled badly, the app may crash, expose internal details, or fail open by allowing access when a check throws an error.

Defence: handle errors explicitly; fail closed (deny when unsure); return generic error messages to users and keep details in logs; test the unhappy paths.

def is_allowed(user, order):
    try:
        return check_policy(user, order)
    except Exception:
        # Fail closed: if the check itself breaks, deny.
        return False

If check_policy crashes, access is denied. The opposite mistake, returning True in the except branch, would grant access exactly when something is broken.

Typical questions: "Name five OWASP Top 10 risks." "What is broken access control and how do you prevent it?" "How do you prevent SQL injection?" Do not just recite the list. Pick two items you understand deeply, explain how the attack works at a high level, show the vulnerable pattern and the fix, and say how you would test for it. Mention that you know the list is updated, and which edition you studied.

Act as an interviewer for a junior developer role. Ask me one question at a time about the OWASP Top 10:2025 categories [list the ones you want to practise, e.g. A01, A05, A07]. After each of my answers, tell me what was good, what was missing, and give a better model answer in 3 or 4 sentences. Keep it defensive: no step-by-step attack instructions.

What to expect: Compare the model answers with the official OWASP pages. If the AI names categories that do not match the official list, trust the official site.