Intermediate · Malware and web security · topic 26 of 43 · 40 min
The OWASP Top 10 with fixes
Explanation
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.
| Risk | What goes wrong | Fix |
|---|---|---|
| A01 Broken access control | Users reach data or actions that are not theirs, like changing /orders/1005 to /orders/1006 | Check ownership and role on the server for every request; deny by default |
| A02 Cryptographic failures | Sensitive data unprotected: no HTTPS, plain-text or weakly hashed passwords | TLS everywhere, Argon2id or bcrypt for passwords, encrypt sensitive fields |
| A03 Injection | Input treated as code: SQL injection, command injection, cross-site scripting (XSS) | Parameterised queries, never build commands from strings, encode output |
| A04 Insecure design | The design itself is unsafe, like unlimited OTP attempts | Threat-model features; add limits and approvals by design |
| A05 Security misconfiguration | Debug mode on, default passwords, public storage, verbose errors | Hardened, repeatable configuration; review before release |
| A06 Vulnerable and outdated components | Old libraries with known CVEs | Inventory dependencies, update, scan (npm audit, pip-audit) |
| A07 Identification and authentication failures | No rate limits on login, weak session handling | Rate limits, MFA, secure session cookies, lockouts |
| A08 Software and data integrity failures | Trusting code or data without checking, like unsigned updates | Signed builds and updates, trusted package sources, lock files |
| A09 Security logging and monitoring failures | Attacks happen and nobody notices | Log 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 ones | Allow-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.
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))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 <), 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
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)
A logged-in user changes /invoice/101 to /invoice/102 and sees another customer's invoice. Which risk?
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.
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
Read more (free)
Related help
Before this, learn
This topic builds on these. If something here feels new, open them first.
Related topics
- Secure coding basicsMalware and web security · same module
- Malware types and how they get inMalware and web security · same module
- The OWASP Top 10: the most common web risksBackend Development · Backend security
- The OWASP approach to web testingEthical Hacking and Penetration Testing (legal labs) · Web application testing: Burp Suite and the basics
- Cross-site scripting (XSS)Ethical Hacking and Penetration Testing (legal labs) · Web attacks and their fixes
- SQL injection and how to stop itBackend Development · Backend security
Questions people ask about this
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.
Which OWASP resource gives short, practical fixes?Related
Answer: The Cheat Sheet Series
The OWASP Cheat Sheet Series gives concise fix guidance.
Modern frameworks like React reduce XSS because they…Related
Answer: Encode output by default
They escape interpolated values by default.
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.
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 more topic in “Malware and web security” before its exam: Secure coding basics.
- Module 6 exam: Malware and web security · 13 questions · 25 min, without help. 4 topics of this module still to finish first.
- Then the next module, Cloud security basics. 43 topics left in the course before the final exam.