Think like a defender: network attack surface, threat modeling, the OWASP Top 10, core controls, identity, cryptography, frameworks and the rules of ethical testing.

Cybersecurity Fundamentals

Draw the data flow diagram: the user's browser, the web app, the database, the email provider and the admin user. Connect them with labelled arrows showing what data moves.

Draw a dashed trust boundary wherever data crosses between the internet, your server and the email provider.

For each arrow that crosses a trust boundary, write at least one threat for each STRIDE letter that applies (aim for 8 or more threats in total).

Add one threat that involves the share link (for example: who can open it, and for how long?).

Add one threat that involves the admin page (for example: how does the server check that the caller really is an admin?).

Rate each threat high, medium or low for likelihood and for impact, and circle the three worst.

For each of the three worst, write a mitigation and say whether you mitigate, eliminate, transfer or accept it.

Write one sentence on what would make you revisit this model (for example, a new feature or integration).

## Why it matters

Most security work is reactive: a scanner finds a bug, an alert fires, a patch comes out. **Threat modeling** is the proactive part. Before (or while) a system is built, you ask "what could go wrong?" in an organised way, so problems get fixed on a whiteboard instead of in an incident report. It is cheap, it needs no special tools, and it is one of the most useful skills a security engineer can bring to a development team.

## The core idea: four questions

A widely used framing, popularised by Adam Shostack and the Threat Modeling Manifesto, reduces threat modeling to four questions:

1. **What are we working on?** Draw the system.
2. **What can go wrong?** Find threats.
3. **What are we going to do about it?** Choose mitigations.
4. **Did we do a good enough job?** Review and revisit.

### Step 1: draw a data flow diagram

A **data flow diagram (DFD)** needs only four shapes:

- **External entities** (rectangles): people or systems outside your control, such as a user or a payment provider.
- **Processes** (circles): your code, such as a web app or an API.
- **Data stores** (two parallel lines): databases, file storage, caches.
- **Data flows** (arrows): data moving between the others, labelled with what moves.

Then add **trust boundaries**: dashed lines wherever data crosses from one level of trust to another, such as the internet to your server or your server to a third-party API. Most threats live where arrows cross those lines.

### Step 2: find threats with STRIDE

STRIDE, created at Microsoft, is a checklist of six threat types. Each one breaks a security property:

| Threat | Breaks | Example | Typical mitigation |
|---|---|---|---|
| **S**poofing | Authentication | Logging in as another user with a stolen password | Strong authentication, MFA |
| **T**ampering | Integrity | Changing a price in a request before it reaches the server | Server-side validation, signatures, TLS |
| **R**epudiation | Non-repudiation | A user denies deleting a record and there is no evidence | Audit logs that users cannot edit |
| **I**nformation disclosure | Confidentiality | An error page shows a database password | Least privilege, encryption, generic errors |
| **D**enial of service | Availability | Flooding the login endpoint until the site falls over | Rate limits, quotas, scaling |
| **E**levation of privilege | Authorization | A normal user reaches an admin page by changing the URL | Server-side access checks on every request |

Walk each element of the DFD, especially each flow that crosses a trust boundary, and ask "how could S, T, R, I, D or E happen here?"

### Step 3: decide what to do

For each threat, pick one response:

- **Mitigate**: add a control (most common).
- **Eliminate**: remove the feature or data that creates the risk.
- **Transfer**: let someone better placed handle it (for example, use a payment provider instead of storing card numbers).
- **Accept**: document that the risk is low enough and who agreed to accept it.

Rank threats roughly by **likelihood x impact** so the team fixes the worst first. A simple high/medium/low scale is enough for beginners.

## Worked example: a recipe-sharing app

The app lets people sign up, post recipes with photos, and comment. The DFD:

```text
[User browser] --(login, recipes, photos)--> (Web app) --(SQL)--> ||Database||
                                              (Web app) --(files)--> ||Photo storage||
                                              (Web app) --(email)--> [Email provider]
 - - - - trust boundary: internet | server - - - -
```

Walking STRIDE across the browser-to-app boundary gives, among others:

- **S**: password guessing on `/login`. Mitigate with rate limits, lockouts and optional MFA.
- **T**: a user edits the hidden `authorId` field to post as someone else. Mitigate by taking the author from the session on the server, never from the request.
- **R**: a user deletes another user's comment and claims they didn't. Mitigate with audit logs of deletions.
- **I**: uploaded photos keep GPS location in their metadata. Mitigate by stripping metadata on upload.
- **D**: someone uploads 2 GB files. Mitigate with a size limit and a per-user quota.
- **E**: `DELETE /recipes/42` works for any logged-in user. Mitigate with an ownership check on the server.

Six concrete, fixable issues, found in about twenty minutes with a whiteboard. That is the whole point.

## Common mistakes

- **Boiling the ocean.** Start with one feature or one diagram. A small model that gets used beats a perfect one that never finishes.
- **Only thinking about outside hackers.** Insiders, buggy integrations and honest mistakes cause incidents too.
- **Treating it as a one-off.** Update the model when the design changes: a new integration means a new trust boundary.
- **Listing threats without owners.** Each mitigation needs an owner and a ticket, or it will not happen.

## Quick recap

- Threat modeling asks four questions: what are we working on, what can go wrong, what will we do, did we do enough.
- Draw a DFD with external entities, processes, stores, flows and trust boundaries.
- Use STRIDE (spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege) on each element and boundary.
- Mitigate, eliminate, transfer or accept each threat, ranked by likelihood and impact.

## Try it

Open the **Do** tab and threat-model a small to-do app on paper.


Threat-model a small app: draw its data flows and trust boundaries, then find threats with STRIDE and choose fixes.

Threat modeling for beginners

STRIDE Threat Modeling for Beginners - In 20 Minutes

## Why it matters

The **OWASP Top 10** is a list of the most critical security risks to web applications, published by the Open Worldwide Application Security Project, a non-profit community. It is built from data contributed by security firms and from a community survey. Developers use it as a checklist, auditors cite it, job interviews ask about it, and certification exams expect you to know it. It is an awareness document, not a complete standard, but it is the best map of where web apps actually break.

The current edition is the **OWASP Top 10:2025**. Read the official pages for full details and examples at [owasp.org/Top10](https://owasp.org/Top10/). Checked on 2026-10-23.

## The 2025 list in plain English

### A01 Broken Access Control
The app lets users do things they should not. Example: changing `/invoices/1001` to `/invoices/1002` shows someone else's invoice (this is called an insecure direct object reference, or IDOR). **Fix:** check ownership and role on the server for every request; deny by default.

### A02 Security Misconfiguration
Unsafe settings: default admin passwords, debug mode on in production, directory listings, verbose error pages, open cloud storage buckets. **Fix:** hardened, repeatable configuration, removing unused features, and automated checks.

### A03 Software Supply Chain Failures
Your app is only as safe as the code and tools it depends on. Examples: an outdated library with a known vulnerability, a malicious package published under a look-alike name, a compromised build pipeline. **Fix:** keep an inventory of dependencies, update them, pin versions, use lockfiles and trusted registries, and protect your CI/CD system.

### A04 Cryptographic Failures
Sensitive data is not protected properly: passwords stored with MD5, data sent over plain HTTP, hard-coded keys, homemade encryption. **Fix:** TLS everywhere, slow salted password hashing (bcrypt, scrypt, Argon2 or PBKDF2), well-known libraries, and proper key management (lesson 3.3).

### A05 Injection
Untrusted input is treated as code. The classic example is SQL injection:

```python
# Vulnerable: the input becomes part of the SQL text
cur.execute("SELECT * FROM users WHERE email = '" + email + "'")

# Safe: a parameterised query keeps data and code separate
cur.execute("SELECT * FROM users WHERE email = ?", (email,))
```

If `email` is `' OR '1'='1`, the vulnerable version returns every user. Cross-site scripting (XSS) is injection into HTML and JavaScript; you will fix one in the next lesson. **Fix:** parameterised queries, safe APIs, output encoding, input validation.

### A06 Insecure Design
The flaw is in the design itself, not a coding slip. Example: a password reset that asks "what is your favourite colour?", or a checkout with no limit on how many gift cards can be tried. **Fix:** threat modeling (previous lesson), secure design patterns, and abuse cases written next to user stories.

### A07 Authentication Failures
Weaknesses in proving who someone is: no protection against password guessing, allowing known-breached passwords, session IDs that do not expire or are not renewed after login. **Fix:** MFA, rate limiting, checks against breached-password lists, and secure session handling.

### A08 Software or Data Integrity Failures
The app trusts code or data without checking it has not been tampered with. Examples: auto-updates downloaded without signature checks, or deserialising untrusted objects that can run code. **Fix:** verify signatures and checksums, and do not deserialise untrusted data into objects.

### A09 Security Logging and Alerting Failures
Attacks happen and nobody notices: failed logins are not logged, logs are never reviewed, no alert fires. Many breaches are discovered months later by outsiders. **Fix:** log security-relevant events (logins, access-control failures, admin actions) without logging secrets, centralise the logs, and alert on suspicious patterns.

### A10 Mishandling of Exceptional Conditions
The app behaves unsafely when something unexpected happens: an error skips a permission check ("fail open"), a crash leaks a stack trace with internal details, or an unhandled edge case leaves data half-written. **Fix:** fail closed (deny when in doubt), handle errors consistently, show generic error messages, and test edge cases.

## How the list changed

Compared with the 2021 edition, the 2025 list moves Security Misconfiguration up to second place, widens "Vulnerable and Outdated Components" into **Software Supply Chain Failures**, folds server-side request forgery into Broken Access Control, and adds **Mishandling of Exceptional Conditions** as a new category. Many tutorials and exam materials still use the 2021 names, so it is worth recognising both.

## Worked example: mapping bugs to categories

A pentest report lists five findings for an online shop. Mapping them:

| Finding | Category |
|---|---|
| Changing `orderId` in the URL shows other customers' orders | A01 Broken Access Control |
| The admin panel still accepts `admin` / `admin` | A02 Security Misconfiguration (and A07) |
| A search box returns a database error when given a single quote | A05 Injection |
| The site uses a JavaScript library version with a published exploit | A03 Software Supply Chain Failures |
| 10,000 failed logins overnight produced no alert | A09 Security Logging and Alerting Failures |

Mapping findings this way helps teams spot patterns: three access-control bugs in one quarter suggest a missing shared authorization check, not three unrelated mistakes.

## Common mistakes

- **Treating the Top 10 as complete.** It covers the most common risks, not all of them. For a fuller checklist, OWASP publishes the Application Security Verification Standard (ASVS).
- **Trusting the client.** Hidden form fields, disabled buttons and JavaScript checks are conveniences. Every rule must be enforced on the server.
- **Fixing symptoms.** Blocking the word `OR` in input does not fix SQL injection; parameterised queries do.

## Quick recap

- The OWASP Top 10 is the standard awareness list of web app risks; the current edition is 2025.
- Access control, misconfiguration, supply chain, cryptography and injection lead the list.
- Most fixes come down to a few habits: enforce rules on the server, keep data separate from code, use proven libraries, keep dependencies current, log and alert, and fail closed.


Name and explain the OWASP Top 10 web application risks, with a plain-English example and fix for each.

OWASP Top 10 explained

OWASP Top 10 2025: Your complete guide to securing your applications

## Why it matters

Cross-site scripting (**XSS**) is one of the most common web vulnerabilities, and it is part of the OWASP Top 10 under Injection. It happens when an app takes text from a user and puts it into a page in a way that the browser runs as code. The attacker's script then runs **in the victim's browser, on your site's origin**, so it can read what the page shows, act as the logged-in user, change the page to show a fake login form, or send data to the attacker.

In this lesson you will look at a tiny comment board, find the flaw, and fix it. Everything happens in the sandboxed exercise on the Do tab, which is a system you are allowed to test. Never try XSS payloads on websites you do not own or have written permission to test.

## The core idea: data versus markup

A browser reads HTML as a mix of **markup** (tags such as `<b>` or `<script>`) and **text**. The bug happens when user input crosses from the "text" side to the "markup" side.

Here is the vulnerable pattern in JavaScript:

```javascript
const comment = input.value;          // whatever the user typed
const li = document.createElement('li');
li.innerHTML = comment;               // parsed as HTML: the flaw
list.appendChild(li);
```

If someone types `Nice recipe!`, all is well. If they type:

```html
<img src="x" onerror="alert(document.domain)">
```

the browser parses it as a real image tag, the image fails to load, and the `onerror` handler runs the attacker's JavaScript. A real attacker would replace the `alert` with code that does something harmful.

The fix is to tell the browser the input is **text**, not markup:

```javascript
li.textContent = comment;             // shown literally, never parsed as HTML
```

Now the same input appears on the page as the literal characters `<img src="x" ...>`, which is harmless.

## The three kinds of XSS

| Type | Where the script comes from | Example |
|---|---|---|
| **Stored** | Saved on the server and shown to every visitor | A comment containing a script, shown to everyone who opens the page |
| **Reflected** | Part of the request, echoed straight back | `/search?q=<script>...</script>` sent to a victim as a link |
| **DOM-based** | Client-side JavaScript moves data from the URL or input into the page | `el.innerHTML = location.hash.slice(1)` |

All three share the same root cause: untrusted data written into an HTML or JavaScript context without being treated as text.

## How defenders prevent XSS

1. **Use safe APIs.** In the browser, prefer `textContent`, `createElement` and `setAttribute` with fixed attribute names over `innerHTML`, `outerHTML`, `insertAdjacentHTML` and `document.write`.
2. **Let the framework escape.** React, Vue, Angular and most server templates escape output by default. Danger starts when you bypass that, for example with React's `dangerouslySetInnerHTML`.
3. **Encode for the context.** Text inside HTML, an attribute value, a URL and a JavaScript string each need different encoding. Template engines handle this; hand-built strings usually get it wrong.
4. **Sanitise when you must allow HTML.** If users really need formatting, use a well-maintained sanitiser library with an allow list of tags, or offer Markdown rendered by a library that escapes raw HTML.
5. **Add a Content Security Policy.** A CSP header such as `script-src 'self'` stops inline scripts and scripts from other sites, which blocks many XSS payloads even if a bug slips through. It is a second layer, not a replacement for fixing the bug.
6. **Protect session cookies.** `HttpOnly` cookies cannot be read by JavaScript, which limits what a successful XSS can steal.

## Worked example: reviewing the code

When you review code for XSS, search for the dangerous sinks:

```bash
grep -rn "innerHTML\|outerHTML\|insertAdjacentHTML\|document.write\|dangerouslySetInnerHTML" src/
```

For each hit, trace backwards: where does the value come from? If any part of it comes from a user, the URL, a database field users can edit, or another system, treat it as untrusted. Then either switch to a safe API or prove the value is sanitised.

A quick way to test your own form during development is to submit a harmless marker such as `<b id="probe">hi</b>`. If the word "hi" appears in bold, the input is being parsed as HTML, and a real payload would work too. If you see the literal tags, the input is being treated as text.

## Common mistakes

- **Blocklisting `<script>`.** Attackers have hundreds of other ways in (`onerror`, `onload`, `javascript:` URLs, SVG). Fix the sink instead.
- **Escaping on input and then decoding later.** Store the original text and encode it at output time, for the context it is used in.
- **Thinking HTTPS prevents XSS.** The payload arrives over HTTPS like any other request.
- **Trusting data from your own database.** Stored XSS is exactly that: data your app saved earlier.

## Quick recap

- XSS happens when user input is parsed as HTML or JavaScript in someone's browser.
- `innerHTML` with untrusted data is the classic sink; `textContent` is the classic fix.
- Stored, reflected and DOM-based XSS share one root cause.
- Layer defences: safe APIs, framework escaping, sanitisers when HTML is needed, CSP and HttpOnly cookies.

## Try it

Open the **Do** tab, find the flaw in the comment board and fix it.


Find a cross-site scripting (XSS) flaw in a small comment board and fix it by treating user input as text.

Find the flaw in this app

Cracking Websites with Cross Site Scripting - Computerphile

Cross-Site Scripting (XSS) Explained

Threat modeling with STRIDE, the OWASP Top 10, and finding and fixing a cross-site scripting flaw.