OWASP Top 10 explained: HSC Software Engineering Module 1
“Identify the OWASP Top 10 web application security risks and describe mitigations for each”
The OWASP Top 10 is the industry-standard list of the most critical web application security risks. Each risk has a concrete attack pattern and a developer-side mitigation. Memorise at least Broken Access Control, Injection, Cryptographic Failures, and Authentication Failures - they appear repeatedly in the HSC exam.
Imagine a shopping centre security manager who has read a report listing the ten most common ways shopping centres get robbed or vandalised, ranked by how often and how badly they happen: an unlocked back door, a guard who does not check ID, a broken camera, and so on. The OWASP Top 10 is exactly that report, but for websites: a ranked list, refreshed every few years by security researchers pooling data from thousands of real breaches, of the ten most common and damaging ways web applications get attacked. Just like the shopping centre report is useless without someone actually locking the back door, knowing the list is not the security control, applying a specific fix for each item, checking IDs at the door for broken access control, replacing the broken camera for missing logging, is what the HSC dot point is really asking you to demonstrate.
What this dot point is asking
NESA wants you to know the standard industry list of the most critical web application security risks, give a concrete example of each, and pair each with a defender-side mitigation. The OWASP Top 10 is updated every few years; the 2021 list is the current reference.
The answer
The Open Worldwide Application Security Project (OWASP) publishes the Top 10 web application security risks. The 2021 list:
For full marks on any OWASP question, give: (1) the CATEGORY name (e.g. "A01: Broken Access Control"), (2) a CONCRETE attack example specific to the scenario in the question, and (3) a NAMED developer-side mitigation (a technique, tool, or pattern - never "be more careful").
A01: Broken Access Control
Users can access resources or perform actions they should not. Example: changing /api/users/123/profile to /api/users/124/profile returns another user's data because the server only checks login, not ownership.
Mitigation: enforce authorisation on every endpoint with object-level checks. Deny by default. Test with unauthorised, low-privilege, and high-privilege accounts.
A02: Cryptographic Failures
Sensitive data is exposed because it was not encrypted properly. Example: passwords stored as plain text or with MD5, payment data sent over HTTP.
Mitigation: HTTPS everywhere, bcrypt or Argon2 for passwords, AES-256 for data at rest, secrets in a key management service.
A03: Injection
Untrusted input is interpreted as code. SQL injection is the headline example, but command injection, LDAP injection, and template injection are all in this category.
Mitigation: parameterised queries, output encoding, allow-list input validation, ORMs that parameterise by default.
A04: Insecure Design
Security flaws baked in at the design stage that no amount of code review can fix. Example: a "password reset" flow that sends the user's current password by email.
Mitigation: threat modelling during design, secure design patterns, reference architectures.
A05: Security Misconfiguration
Default credentials, unnecessary services left on, verbose error messages exposing stack traces. Example: a production database with the default admin password.
Mitigation: hardened configuration, automated configuration scans, principle of least functionality.
A06: Vulnerable and Outdated Components
Using a library with a known CVE (Common Vulnerabilities and Exposures). Example: Log4j 2.14 (Log4Shell).
Mitigation: dependency scanning (npm audit, pip-audit, Snyk, Dependabot), patch promptly, remove unused dependencies.
A07: Identification and Authentication Failures
Weak or missing authentication: brute-forceable login, no MFA, predictable session IDs.
Mitigation: MFA, rate limiting, account lockout, secure session management, password breach checks.
A08: Software and Data Integrity Failures
Trusting code or data without verifying its integrity. Example: pulling an auto-update from an unsigned source, deserialising untrusted data.
Mitigation: signed artefacts, integrity checks (hash, signature), supply chain security tooling.
A09: Security Logging and Monitoring Failures
The system does not log enough to detect or investigate attacks. Example: no record of failed logins, no alert on a thousand-per-second login attempt.
Mitigation: structured logs of security events, centralised log aggregation, alerts on anomalies.
A10: Server-Side Request Forgery (SSRF)
The server makes outbound requests based on user input, allowing an attacker to reach internal services. Example: a "preview this URL" feature that fetches http://localhost/admin.
Mitigation: validate URL targets against an allow-list, block requests to private IP ranges, segregate networks.
A chart ranks the ten categories by how many separate CIA-triad principles they typically threaten at once, showing why some risks (like Injection) are treated as higher-severity: they can breach multiple principles through a single flaw.
A worked SQL injection example
A vulnerable query (do not write this):
def get_user(username):
query = f"SELECT * FROM users WHERE name = '{username}'"
return db.execute(query).fetchone()
Submitting admin' OR '1'='1 as the username turns the query into:
SELECT * FROM users WHERE name = 'admin' OR '1'='1'
which returns every user.
The fix - a parameterised query:
def get_user(username):
query = "SELECT * FROM users WHERE name = ?"
return db.execute(query, (username,)).fetchone()
The database driver substitutes ? with the value safely. The input can no longer change the query structure.
Keep a one-line mental template per category: "A0N: [name] - an attacker [does X] because [Y is missing] - fixed by [named control]." Rehearsing this template for at least Broken Access Control, Injection, Cryptographic Failures and Authentication Failures covers most HSC questions, since these four dominate past papers. If a scenario does not obviously match one category, check whether it is a DESIGN flaw (A04, present before any code was written) versus an IMPLEMENTATION or CONFIGURATION flaw (most other categories, introduced while building or deploying).
A school portal lets students submit feedback through a form. Identify three OWASP risks the developer should consider and a mitigation for each.
A03 Injection (XSS): an attacker submits a script tag as feedback, which then executes in the browser of any admin who reads the queue. Mitigation: HTML-encode all user input when rendering.
A01 Broken Access Control: a student crafts a request to view another student's submitted feedback. Mitigation: every endpoint checks the requester is the owner of the resource.
A07 Authentication Failure: the form is open to anonymous submissions but the rate limit allows a single user to flood the queue. Mitigation: per-IP rate limit, CAPTCHA on anonymous submissions, account-based rate limit on logged-in users.
- Reciting the list without examples
- Markers want a concrete attack scenario for each risk, not just the title.
- Treating mitigation as "be careful"
- A specific developer-side action (parameterised queries, HTTPS, dependency scanner) is what scores.
- Confusing OWASP Top 10 with CIA triad
- Different abstractions. The Top 10 is a list of attack categories. CIA is a list of security goals. Each Top 10 risk usually maps to one or two CIA principles.
- Quoting the wrong version
- The current list is 2021. If you cite the 2017 list (which had different ordering, separate XSS and Injection categories), markers may dock you for currency.
Exam-style questions
Questions in the style of NESA exam questions on this dot point, each with a worked answer. They are written by ExamExplained unless tagged "Past paper"; the year shows the paper a question is modelled on.
Practice6 marksIdentify three risks from the OWASP Top 10 and for each describe a mitigation that a developer can implement during the secure development lifecycle.Show worked answer →
- Injection (SQL injection)
- An attacker submits crafted input that gets interpreted as code by a backend interpreter, typically a SQL database. Mitigation: use parameterised queries (also called prepared statements) so user input is always treated as data, never as code. Never build SQL strings by concatenation. Validate input against an allow-list.
- Broken access control
- A logged-in user can access resources they should not, such as another user's account by guessing the URL. Mitigation: enforce authorisation checks on every server endpoint, not just in the UI. Use object-level authorisation: every request to /api/orders/123 checks that the current user owns order 123. Deny by default.
- Cryptographic failures
- Sensitive data (passwords, payment info, tokens) is stored or transmitted insecurely. Mitigation: enforce HTTPS site-wide, hash passwords with bcrypt/Argon2 and per-user salts, store secrets in a key management service (not in source code), and use AES-256 for data at rest.
Markers reward three distinct risks correctly named from the OWASP list, a concrete attack example for each, and a specific developer-side mitigation (not just "be careful"). Best answers tie mitigations back to the secure development lifecycle (threat modelling, code review, dependency scanning, security testing).
Practice questions
Original practice questions graded from foundation to exam level, each with a full worked solution. Try them before revealing the solution.
foundation3 marksMatch each scenario to the correct OWASP Top 10 (2021) risk category: (a) a production admin panel is still using the default password 'admin123', (b) a web form does not filter user comments before storing them in the database used to build a SQL string, (c) a password reset link never expires and is guessable.Show worked solution →
(a) A05: Security Misconfiguration - a default credential left unchanged in production.
(b) A03: Injection - unfiltered input concatenated into a SQL string is classic SQL injection.
(c) A07: Identification and Authentication Failures - a non-expiring, guessable reset token is a weak authentication mechanism.
Marking criteria: 1 mark per correctly matched category (3 marks total); the exact A0-number is not required if the category name is correct.
foundation4 marksFor the risk 'A06: Vulnerable and Outdated Components', explain what it is, give one realistic example, and state one specific mitigation a development team could put in an automated CI pipeline.Show worked solution →
What it is: using a software library, framework or component with a known security vulnerability (a published CVE), often because it has not been updated.
Example: a web application running an old version of the Log4j logging library affected by the Log4Shell vulnerability, allowing remote code execution via a crafted log message.
CI pipeline mitigation: add an automated dependency scanner (e.g. npm audit, pip-audit, Snyk, or GitHub Dependabot) as a required step in the build pipeline that fails the build if a dependency with a known high-severity CVE is detected, forcing the team to patch before deploying.
Marking criteria: 1 mark for a correct explanation, 1 mark for a realistic named example, 2 marks for a specific, automatable mitigation (not just "update libraries").
core5 marksThe table below shows four incidents reported to a company's security team in one month. For each, name the most applicable OWASP Top 10 (2021) category and justify your choice in one sentence.
| Incident | Detail |
|---|---|
| 1 | An attacker changed a hidden order-total field in a request and paid $1 for a $500 item |
| 2 | A support script silently deserialises an uploaded file without checking its origin |
| 3 | No one noticed 40,000 failed login attempts against one account over a weekend |
| 4 | A newly built 'refer a friend' feature emails the referrer's password in plain text as a 'reminder' |Show worked solution →
Incident 1: A01: Broken Access Control (or could be argued as Insecure Design if the price should never have been client-controlled) - the server trusted client-supplied data to determine the price instead of enforcing the true price server-side; the safest classification is Broken Access Control because the client was allowed to control a value it should not have authority over.
Incident 2: A08: Software and Data Integrity Failures - deserialising untrusted, unverified data can execute attacker-controlled code embedded in the file.
Incident 3: A09: Security Logging and Monitoring Failures - the failed logins were not detected because there was no alerting on an anomalous volume of authentication failures.
Incident 4: A04: Insecure Design - emailing a plaintext password is a flaw baked into the design of the feature itself; no amount of secure coding practice fixes a feature that is designed to expose secrets.
Marking criteria: 1 mark per correctly matched category (4 marks), 1 mark for a justification that correctly distinguishes design-stage flaws (A04) from operational access-control or monitoring gaps.
core5 marksExplain how A03: Injection and A07: Identification and Authentication Failures could combine in a single attack against a login system, and describe one mitigation for each that would jointly close the attack.Show worked solution →
The combined attack: an attacker first exploits a SQL injection vulnerability in the login form (A03) to bypass the password check entirely (e.g. submitting ' OR '1'='1 as the password), gaining access to an account without ever needing a valid credential. Even if injection were fixed, a system with weak authentication (A07), such as no rate limiting, would let the same attacker instead brute-force weak passwords directly, achieving a similar outcome through a different route.
Mitigation for A03: use parameterised queries for the login lookup, so the password field can never alter the SQL query's structure regardless of its content.
Mitigation for A07: enforce account lockout or exponential rate limiting after repeated failed attempts, and require multi-factor authentication for sensitive accounts, so even a correctly guessed or leaked password is not sufficient alone.
Together, these close both the "bypass via injection" and the "guess via brute force" paths into the same login system, which is why real security reviews check the Top 10 as a set rather than one risk at a time.
Marking criteria: 2 marks for correctly explaining how the two risks combine into related attack paths on the same feature, 1 mark each for a correct, specific mitigation per risk (2 marks).
exam7 marksA start-up is launching a food delivery app in three months. Evaluate which THREE OWASP Top 10 risks the team should prioritise given limited security budget, and justify your ranking with reference to the app's likely attack surface (customer accounts, payment details, and a driver-tracking API).Show worked solution →
This is an extended-response evaluate question: markers reward a justified ranking tied to the SPECIFIC attack surface described, not a generic recitation of the Top 10.
- Priority 1: A02 Cryptographic Failures
- The app stores payment details and customer accounts, both high-value targets; if payment data or passwords are exposed through weak or missing encryption, the financial and reputational damage (and regulatory exposure, e.g. PCI-DSS obligations for payment data) is immediate and severe. Mitigation: HTTPS everywhere, bcrypt/Argon2 for passwords, tokenised or PCI-compliant handling of card data rather than storing raw card numbers.
- Priority 2: A01 Broken Access Control
- A driver-tracking API is a classic target for object-level authorisation bugs, e.g. one customer viewing another customer's live order location by changing an order ID in the API call. Given the app exposes real-time location data (a privacy-sensitive attack surface unique to delivery apps), enforcing per-request ownership checks on every driver/order endpoint is a high-impact, achievable fix even on a small budget.
- Priority 3: A03 Injection
- Login and search endpoints (restaurant search, address lookup) are common injection targets; SQL injection against the customer or order database could expose the same payment and account data protected in Priority 1, making it a natural third layer of defence. Mitigation: parameterised queries used consistently across all database access.
- Why not top-3 for the rest
- Risks like A06 (Vulnerable and Outdated Components) and A09 (Logging and Monitoring) matter but are cheaper to defer briefly (a first dependency scan can be added post-launch, and initial manual log review can substitute for full alerting for a few weeks), whereas a payment data leak, a location-privacy leak, or a login bypass could each cause irreversible harm and public trust loss in the app's first weeks.
Marking criteria: 1 mark per correctly justified top-3 risk tied to the app's specific attack surface (3 marks), 2 marks for concrete, budget-appropriate mitigations per priority (distributed), 2 marks for explicit reasoning about WHY the excluded risks were deprioritised rather than simply omitted.
exam6 marksAssess the claim that 'fixing A03: Injection is sufficient to make a web application secure', using at least two other Top 10 risks that would remain unaddressed.Show worked solution →
A strong assess response takes a position, supports it with named counter-examples, and gives a final judgement.
- Position
- The claim is false. Injection is one of ten distinct risk categories; fixing it removes one attack class but leaves several independent categories of vulnerability untouched.
- Counter-example 1: A01 Broken Access Control
- Even with injection fully fixed (e.g. all queries parameterised), a server that fails to check whether the current user OWNS a resource before returning it is still broken; this is a logic flaw in authorisation code, entirely unrelated to how the database is queried.
- Counter-example 2: A05 Security Misconfiguration
- A perfectly injection-safe application deployed with default admin credentials, an exposed debug console, or verbose stack traces in production error pages is still highly exploitable, again through a route that has nothing to do with injection.
Counter-example 3 (optional strengthener): A07 Identification and Authentication Failures. An application with no injection vulnerabilities at all can still be compromised if attackers can brute-force weak passwords with no rate limiting or MFA.
Judgement. Injection is a necessary risk to fix because it is a common, high-impact attack class, but the OWASP Top 10 exists precisely because web application security requires defending against MULTIPLE independent categories of flaw at once; fixing one category provides no protection against the others, so the claim significantly understates the scope of what "secure" requires.
Marking criteria: 2 marks for a clear position, 3 marks for at least two correctly explained counter-example risks that are genuinely independent of injection, 1 mark for an explicit final judgement.