Skip to content

Intermediate · Malware and web security · topic 26 of 43 · 40 min

The OWASP Top 10 with fixes

Explanation

The OWASP Top 10 is a free, widely used list of the most serious risks in web applications, such as broken access control and injection. Security teams, developers and auditors use it as a shared checklist. For each risk there is a clear fix, like checking permissions on the server and using parameterised queries.

Why web apps matter

Banking, shopping, government services and company tools are all web apps or APIs. They face the whole internet, so their bugs are found quickly. OWASP (Open Worldwide Application Security Project) is a non-profit community that publishes free guides; its Top 10 lists the most common and serious web risks, based on data from many organisations.

The list and its fixes

The table uses the 2021 names, which are still the ones most courses, exams and interviews use. OWASP released a newer 2025 edition: it keeps broken access control at number one, adds software supply chain failures and mishandling of exceptional conditions, and folds server-side request forgery into broken access control. Always check owasp.org for the current list.

RiskWhat goes wrongFix
A01 Broken access controlUsers reach data or actions that are not theirs, like changing /orders/1005 to /orders/1006Check ownership and role on the server for every request; deny by default
A02 Cryptographic failuresSensitive data unprotected: no HTTPS, plain-text or weakly hashed passwordsTLS everywhere, Argon2id or bcrypt for passwords, encrypt sensitive fields
A03 InjectionInput treated as code: SQL injection, command injection, cross-site scripting (XSS)Parameterised queries, never build commands from strings, encode output
A04 Insecure designThe design itself is unsafe, like unlimited OTP attemptsThreat-model features; add limits and approvals by design
A05 Security misconfigurationDebug mode on, default passwords, public storage, verbose errorsHardened, repeatable configuration; review before release
A06 Vulnerable and outdated componentsOld libraries with known CVEsInventory dependencies, update, scan (npm audit, pip-audit)
A07 Identification and authentication failuresNo rate limits on login, weak session handlingRate limits, MFA, secure session cookies, lockouts
A08 Software and data integrity failuresTrusting code or data without checking, like unsigned updatesSigned builds and updates, trusted package sources, lock files
A09 Security logging and monitoring failuresAttacks happen and nobody noticesLog logins, failures and admin actions; alert on them
A10 Server-side request forgery (SSRF)The server is tricked into fetching an attacker-chosen URL, even internal onesAllow-list destinations, block internal and cloud metadata addresses

Injection, up close

SQL injection happens when user input is glued into an SQL query as text. The database cannot tell your query from the attacker's input. The fix is a parameterised query: the query and the data are sent separately, so input is always treated as data.

python
import sqlite3

db = sqlite3.connect(":memory:")
db.execute("CREATE TABLE users (name TEXT, role TEXT)")
db.executemany("INSERT INTO users VALUES (?, ?)", [("asha", "admin"), ("ravi", "staff")])

name = "nobody' OR '1'='1"
unsafe = db.execute(f"SELECT * FROM users WHERE name = '{name}'").fetchall()
safe = db.execute("SELECT * FROM users WHERE name = ?", (name,)).fetchall()
print(len(unsafe), len(safe))
The unsafe query returns every row (2) because the input changed the logic. The parameterised query returns 0. Shows 2 0.

Broken access control, up close

An IDOR (insecure direct object reference) is a common access control bug: the app uses an ID from the request without checking it belongs to the user. Hiding a button is not access control; attackers call the API directly. Every request must be checked on the server.

Cross-site scripting (XSS)

XSS is injection into a web page: an attacker gets their script into a page that other users view, for example in a comment. The browser runs it as if it came from the site, and it can steal session data or act as the user. Fixes: encode output (turn < into &lt;), use frameworks that escape by default, add a Content-Security-Policy, and set HttpOnly on session cookies.

Detection matters too

  • A web application firewall (WAF) blocks common attack patterns and logs attempts.
  • Web logs show probing: many 404s, quotes and SQL words in parameters, 500 errors.
  • Practise only on legal targets: OWASP Juice Shop or DVWA in your own lab, or PortSwigger Web Security Academy.

Common mistakes

  • Relying on front-end checks only.
  • Escaping input "by hand" with replace() instead of using parameterised queries and the framework's encoder.
  • Showing full error messages and stack traces to users.
  • Forgetting APIs and mobile app back-ends; they need the same checks as the website.

Need help?

Stuck on a word or an idea? Search this course, or every course, and jump straight to the explanation or a worked question.

Try:

Watch the lesson

The OWASP Top 10 with fixes · 1/7

Public apps, public bugs

Web apps face the whole internet, so their bugs are found fast.

Prefer a video by a teacher? Find free videos on “OWASP Top 10 explained with examples and fixes” on YouTube ↗

In real life: Changing one number in the URL

A bug bounty researcher testing an Indian travel site, inside the published programme scope, noticed that the booking page /api/bookings/58213 returned another traveller's name, phone and PNR when the number was changed. This is broken access control (IDOR). The developers added a server-side check that the booking belongs to the logged-in user, returned 404 otherwise, and added an alert for one account requesting many different booking IDs.

Practice (0/3 done)

Task 1 · Question

A logged-in user changes /invoice/101 to /invoice/102 and sees another customer's invoice. Which risk?

Task 2 · Code · Python

find_user(db, name) builds its SQL with an f-string, so the input "nobody' OR '1'='1" returns every user. Fix it with a parameterised query (a ? placeholder) so it returns only exact matches, as a list of (name, role) tuples.

Task 3 · Practice

In your own lab, run OWASP Juice Shop (for example with Docker) or sign up for PortSwigger Web Security Academy, and complete one access control lab and one SQL injection lab. For each, write the bug, how you found it, and the fix a developer should make.

Quick quiz

Question 1

1.Which is the correct fix for SQL injection?

Question 2

2.Debug mode left on in production, showing stack traces to users, is…

Question 3

3.An app uses a library version with a known critical CVE. Which risk?

Question 4

4.What does output encoding prevent?

Question 5

5.An OTP check allows unlimited guesses. Which risk is this best described as?

Read more (free)

Open a question to see the answer and why. The first ones are this topic's own quiz, so try the quiz above before you peek.

Which is the correct fix for SQL injection?

Answer: Parameterised queries

Parameterised queries keep data separate from the SQL code.

Debug mode left on in production, showing stack traces to users, is…

Answer: Security misconfiguration

Wrong settings in production are misconfiguration.

An app uses a library version with a known critical CVE. Which risk?

Answer: Vulnerable and outdated components

Known-vulnerable dependencies are A06 in the 2021 list.

What does output encoding prevent?

Answer: Cross-site scripting: the browser shows the text instead of running it

Encoding < and > stops injected HTML/script from executing.

An OTP check allows unlimited guesses. Which risk is this best described as?

Answer: Insecure design (and authentication failure)

The design forgot to limit attempts; it also weakens authentication.

Why should you check the official OWASP page for the Top 10?Related

Answer: The list is updated every few years and names can change

OWASP updates the list every few years using new data, so the latest edition may merge, rename or reorder items.

From The OWASP Top 10: the most common web risks

Which OWASP resource gives short, practical fixes?Related

Answer: The Cheat Sheet Series

The OWASP Cheat Sheet Series gives concise fix guidance.

From The OWASP approach to web testing

Modern frameworks like React reduce XSS because they…Related

Answer: Encode output by default

They escape interpolated values by default.

From Cross-site scripting (XSS)

What causes SQL injection?Related

Answer: Joining user input directly into SQL text

When user text is glued into the query, it can change the query itself. That is injection.

From SQL injection and how to stop it

Pass the quiz (60% or more) or mark this topic as done when you are ready.

Your progress is saved on this device only.

Next steps

  1. 1 more topic in “Malware and web security” before its exam: Secure coding basics.
  2. Module 6 exam: Malware and web security · 13 questions · 25 min, without help. 4 topics of this module still to finish first.
  3. Then the next module, Cloud security basics. 43 topics left in the course before the final exam.

← Previous: How defenders detect malware