Chapter 4 — Our running example: SecureShop
To keep this concrete, we'll secure the same system throughout the guide. Every Part adds a layer.
The system
+-------------------------------------------+
customers ------> | shop.securesh.op (web + API) |
| - browse products |
| - log in / register |
| - place orders, save card details |
+---------------+---------------------------+
|
+---------------v---------------------------+
| orders-api (internal service) |
+---------------+---------------------------+
|
+---------------v---------------------------+
| PostgreSQL: users, orders, payment tokens |
+--------------------------------------------+
staff -----> admin.securesh.op (admin panel, SSH to the servers)
What we have to protect
| Asset | Property that matters | Why |
|---|---|---|
| Customer passwords | Confidentiality | Reused elsewhere; a breach harms people directly |
| Payment tokens | Confidentiality + Integrity | Money, and PCI-DSS obligations |
| Order data | Confidentiality (per-customer) | Alice must not read Bob's orders |
| The price field | Integrity | A customer changing the price is fraud |
| The site itself | Availability | Downtime is lost revenue |
| Admin access | All three | Full compromise if lost |
How each Part contributes
| Part | Adds to SecureShop |
|---|---|
| 2 — Encoding | Understanding why the session token being Base64 protects nothing |
| 3 — Hashing | Storing passwords so a breach doesn't hand over accounts |
| 4 — Symmetric | Encrypting payment tokens at rest, correctly |
| 5 — Asymmetric | Signing API requests; the keys behind TLS |
| 6 — Post-quantum | Making sure today's traffic isn't readable in 2035 |
| 7 — TLS | HTTPS that actually resists interception; internal mTLS |
| 8 — SSH | Staff access to servers without passwords |
| 9 — Network | Segmenting the database away from the internet |
| 10 — Web | Fixing injection, broken access control, session flaws |
| 11 — Operations | Detecting the breach you didn't prevent |
| 12 — Projects | Building all of it for real |
Practice (10 min, no code)
Before you learn any of the answers, write your instinct in notes.md:
- How would you store the passwords?
- Where would you store the key that encrypts payment tokens?
- How would you stop a customer viewing another customer's order?
- What stops someone changing the price in the checkout request?
Keep your answers. In Chapter 52 you'll compare them against what you've learned. Most people get at least two badly wrong, and seeing that is the point.
Further reading
- Article: "Threat Modeling: 12 Available Methods" — Carnegie Mellon SEI. A good survey before Chapter 52.
- Tool: OWASP Threat Dragon — free threat-modelling tool; try it on SecureShop after Chapter 52.
End of Part 1 — Milestone check
- I can name the CIA triad and give a real failure for each
- I can explain what a trust boundary is and what happens there
- I can state the encoding / encryption / hashing difference from memory
- I know the difference between authentication and authorization
- I have written a threat model for one system I know
- My lab is built and Juice Shop runs