Module 9: Web & application security

Estimated time: 4-6 hours (including the labs) · Prerequisites: M2 (networking), M8 (SOC ops)

Most of the data breaches you'll read about start with a vulnerable web application. This module explains how web apps work, the standard list of ways they break (the OWASP Top 10), how defenders fix them, and (importantly) where you're legally allowed to practise attacking them.

Security+ SY0-701 mapping: Domain 2 (Threats, Vulnerabilities & Mitigations) and Domain 3 (Security Architecture).

Licence note: this module is CC BY-SA 4.0

This module adapts material from the OWASP Top 10, which is published under CC BY-SA 4.0. Because of the "ShareAlike" obligation, this single module is therefore itself licensed CC BY-SA 4.0, unlike the rest of this course, which is all rights reserved. If you reuse this module, you must keep it under CC BY-SA 4.0 and attribute the OWASP Foundation. See the attributions page for the full credit.

What you'll get from this module

• Trace what happens when you load a web page: browser → HTTP → server → database.
• Name and explain the OWASP Top 10 (2025) categories in plain English.
• Explain the beginner "big three": SQL injection, XSS, and broken access control (IDOR).
• Describe how defenders fix each: parameterised queries, output encoding, access checks, patching.
• See where web security shows up in SOC work (WAF alerts, web log analysis).
• Know the only legal ways to practise these skills.

---

1. How a web application works

Building on M2, here's the round trip when you open a web app:

1. Your browser sends an HTTP request to a server (e.g. GET /account?id=42).
2. The web/application server runs code to handle that request.
3. That code often queries a database for data (your account details).
4. The server builds a response (usually HTML/JSON) and sends it back.
5. Your browser renders it.

Every one of those hops is an opportunity to attack or defend. Attackers manipulate the request (change id=42 to id=43), abuse the server code (trick it into running unintended commands), or target the database (make it return data it shouldn't). Defenders validate input, enforce access checks, and encode output at each hop.

---

2. The OWASP Top 10 (2025)

The OWASP Top 10 is the security industry's standard awareness list of the most critical web application risks, maintained by the non-profit OWASP Foundation. It's revised every few years; the current edition is 2025 (it succeeds the widely-cited 2021 list). The ten categories, in plain English:

#	Category	Plain-English meaning
A01	Broken Access Control	Users can reach data or actions they shouldn't, e.g. viewing someone else's account or using admin functions as a normal user. Still the #1 risk (and in 2025 it absorbs Server-Side Request Forgery).
A02	Security Misconfiguration	Insecure defaults, unnecessary features left on, verbose error messages, unpatched settings, default credentials. (Rose from A05 in 2021.)
A03	Software Supply Chain Failures	Risk inherited from the components and pipeline your app is built from: vulnerable or outdated libraries, and compromised dependencies or build systems. (Expanded in 2025 from 2021's "Vulnerable and Outdated Components".)
A04	Cryptographic Failures	Sensitive data isn't properly protected: weak or missing encryption, passwords stored badly, secrets sent in the clear.
A05	Injection	Untrusted input is fed into an interpreter (SQL, OS commands, LDAP) and executed as code. Includes SQL injection and cross-site scripting (XSS).
A06	Insecure Design	The flaw is in the design, not a coding bug, a missing security control that no amount of clean code can fix later.
A07	Authentication Failures	Weaknesses in proving who a user is: weak passwords, broken session handling, no protection against credential stuffing. (Renamed from "Identification and Authentication Failures".)
A08	Software or Data Integrity Failures	Trusting code or data that hasn't been verified: unsigned updates, compromised build pipelines, insecure deserialisation.
A09	Security Logging and Alerting Failures	Not logging enough, or not acting on the logs, so attacks go undetected. (The gap a SOC exists to close.)
A10	Mishandling of Exceptional Conditions	Errors and edge cases handled insecurely: leaking detail in error messages, or failing "open" (into an insecure state) instead of failing safe. (New in 2025.)

What changed since 2021: Broken Access Control stays #1. Security Misconfiguration rose to #2. Software Supply Chain Failures (A03) is the big new/expanded entry, and Mishandling of Exceptional Conditions (A10) is brand new. SSRF was folded into A01, and XSS remains part of Injection. If you see the 2021 list elsewhere (it's still everywhere), the concepts carry over. Only the ranking and grouping shifted.

Attribution (TASL): OWASP Top 10:2025, OWASP Foundation, https://owasp.org/Top10/, licensed CC BY-SA 4.0. Category names are OWASP's; the plain-English explanations above are our own paraphrase.

---

3. Deep dive: the beginner "big three"

SQL injection (A05: Injection)

A web app builds a database query using text the user supplied. If the app glues user input straight into the query, an attacker can inject their own SQL.

Imagine a login that builds its query like this (unsafe, illustrative example written for this course):

# UNSAFE — never do this
query = "SELECT * FROM users WHERE email = '" + user_input + "'"

If a user types a normal email it works. But if the attacker types:

' OR '1'='1

...the query becomes SELECT * FROM users WHERE email = '' OR '1'='1', which is true for every row, potentially logging the attacker in as the first user, or dumping the whole table. Injection can read, modify or delete data, and sometimes take over the server.

Cross-site scripting (XSS, under A05, Injection)

XSS is injection aimed at other users' browsers. If an app takes user input (a comment, a profile name) and puts it into a page without encoding it, an attacker can submit input containing a script. When another user views that page, their browser runs the attacker's script, which can steal session cookies, log keystrokes, or perform actions as the victim. The core problem: the browser can't tell the difference between the site's real content and attacker content that got mixed into the page.

Broken access control: IDOR (A01)

IDOR (Insecure Direct Object Reference) is the simplest, most common access-control flaw. Say viewing your invoice loads GET /invoice?id=1005. If the app returns whatever invoice ID you ask for without checking it belongs to you, then changing the URL to id=1006 hands you someone else's invoice. No hacking tools required, just editing a number in the address bar. This class of bug is why A01 is now the #1 risk.

---

4. How defenders fix these

Vulnerability	The fix
SQL injection	Parameterised queries (prepared statements): the database treats user input strictly as data, never as code. Also validate input and apply least privilege to the DB account.
XSS	Output encoding: encode user data for the context it's placed in (HTML, attribute, JS) so the browser renders it as text, not code. Plus a Content Security Policy and input validation.
Broken access control / IDOR	Server-side access checks on every request: verify this user is allowed this object, every time. Never rely on hiding the button or trusting the ID.
Software supply chain (A03)	Patching and dependency management: track what you use (an SBOM helps), update it, and remove what you don't need.

The golden rule underneath all of these: never trust input, and enforce security on the server: anything the browser sends can be forged.

---

5. Where web security meets SOC work

You don't have to be a developer to use this in a SOC role:

• WAF alerts: a Web Application Firewall sits in front of web apps and flags/blocks suspected attacks (injection strings, path traversal). L1 analysts triage WAF alerts constantly: is this a real exploit attempt or a false positive?
• Web log analysis: access logs show requests. Spotting bursts of ' OR '1'='1, encoded payloads, or a single IP walking through id=1, id=2, id=3... is bread-and-butter triage that ties straight back to M8.
• Mapping to ATT&CK: "Exploit Public-Facing Application" is a real ATT&CK technique; recognising these patterns lets you speak the language from M8.

---

🧪 Lab 9: Practise legally and safely

There are two excellent, free, purpose-built ways to practise, and no legitimate alternative that involves other people's systems.

Option A: PortSwigger Web Security Academy (recommended, nothing to install):

The PortSwigger Web Security Academy is free, browser-based, and the industry-standard learning platform for web security. Create an account and start with the SQL injection and Access control learning paths: they map directly to sections 3-4 above. Each lab is an isolated target hosted by PortSwigger specifically for you to attack, so it's completely legal.

Option B: OWASP Juice Shop on your own machine (via Docker, from M1):

Juice Shop is a deliberately vulnerable app you run locally to practise on. Using the Docker skills from M1:

docker run --rm -p 3000:3000 bkimminich/juice-shop

Then browse to http://localhost:3000. It is deliberately full of vulnerabilities, so:

• Run it only on your own machine, never on a shared or work network.
• Stop it after use (the --rm flag deletes the container when you stop it; press Ctrl+C in the terminal, or docker stop the container).

Ethics & the law: read this before you touch any tool

The techniques in this module are only ever legal to practise on:

• platforms built for it (PortSwigger Academy, Juice Shop on your own machine), or
• systems you have explicit written authorisation to test (a signed scope in a job), or
• sanctioned CTF competitions.

Testing these techniques against any website, app or network you don't own and aren't authorised to test is a crime in Australia under the Criminal Code Act 1995 (Cth), Part 10.7 (computer offences: unauthorised access, modification or impairment). "I was just curious" and "I didn't change anything" are not defences. Careers end this way before they start. Keep it in the lab.

Full site terms: terms & disclaimer · something look wrong on this page? Report it.

Lab success = you completed at least one SQL injection lab and one access-control lab on PortSwigger, or found at least two vulnerabilities in a local Juice Shop, and you can explain the fix for each.

---

Self-check

Answer before you reveal: the attempt is what makes it stick. Your score and card ratings are saved on this device only.

Scored self-check

Check your understanding

Commit to an answer before you check: the attempt is what makes it stick. Your first answer to each question is the one scored; practising again afterwards doesn't change it. Saved on this device only.

Question 1 of 7You open your bank’s web page and your account details appear. What actually happened between your click and the page rendering?

Your browser sent an HTTP request; server code handled it, queried the database, and sent back a response your browser renderedYour browser queried the bank’s database directly and rendered the resultThe database pushed your details to the browser as soon as you logged inThe web server passed your request straight to the database, which built the HTML

Question 2 of 7A vulnerability scan flags that your organisation’s web app ships an outdated third-party library with a known flaw. Under the OWASP Top 10 (2025), which category is this?

A05 InjectionA02 Security MisconfigurationA03 Software Supply Chain FailuresA08 Software or Data Integrity Failures

Question 3 of 7Changing id=1005 to id=1006 in a URL shows you another customer’s invoice. Which OWASP category is this, and what’s the fix?

A05 Injection: fix with parameterised queriesA01 Broken Access Control (an IDOR): fix with a server-side authorisation check on every requestA02 Security Misconfiguration: fix by turning off verbose error messagesA07 Authentication Failures: fix with stronger passwords

Question 4 of 7Customers report that simply viewing a certain product review makes their browser run a script that steals their session cookies. What have you found?

SQL injection: the review attacked the databaseAn IDOR: the attacker referenced an object they don’t ownA cryptographic failure: the cookies weren’t encryptedCross-site scripting: attacker input was put into the page without encoding, so victims’ browsers execute it

Question 5 of 7A code review finds a login query built by glueing user input straight into the SQL string. Your team lead asks for the proper fix. What do you recommend?

Put a WAF in front of the appRely on input validation to catch suspicious charactersParameterised queries (prepared statements), so the database treats user input strictly as dataEncrypt the database

Question 6 of 7On WAF alert triage, the access log shows a single IP requesting /invoice?id=1, then id=2, id=3… steadily through the range. What’s your read?

Routine customer browsing: close it as a false positiveLikely enumeration probing for broken access control (IDOR), worth escalatingA burst of SQL injection attemptsCredential stuffing against the login page

Question 7 of 7Your friend asks you to “test” their employer’s website for bugs, since you’re learning all this. What do you say?

Yes, as long as I only look around and don’t change anythingYes, my friend works there, so that counts as permissionYes, but I’ll run Juice Shop on their network so it stays safeNo, without explicit written authorisation it’s a crime; I’ll practise on PortSwigger or a local Juice Shop instead

When a WAF alert lands in your queue there's no time to look up what A01 means. The categories, the big three and their fixes need to be recall-speed, because they're exactly what interviewers and Security+ Domain 2 assume you already have.

Flashcards · spaced repetition

Drill the key terms

Say your answer out loud (or in your head) before revealing. Recall is the workout. "Knew it" pushes a card's next review further out; "Review again" brings it back today.

Card 1 of 18

Prompt

What is the OWASP Top 10?

---

Next module

➡️ M10: Governance, risk & compliance: the #2 entry job: frameworks, risk registers, audits, and where career changers from audit and PM backgrounds shine.