Phase 3 of 5  ·  Quality & Trust
Week 12 / 20   ·   Ch 13

Security
Engineering

"OWASP Top 10 in plain English — every junior dev needs this"

📚 Ch 13 — Security Engineering🔑 Security Design🛡️ OWASP Top 10⏱ ~20 min read

🔍Concept Deep Dives

Click each concept to expand — real examples, diagrams, pros & cons.

🔑

Core Security Concepts

Asset, exposure, vulnerability, attack, threat, control — the vocabulary of security engineering.
⌄

When to Use

Always — you need the right language before you can design security.

Real-World Example

Asset = user passwords. Vulnerability = storing plain text. Attack = SQL injection. Control = bcrypt hashing.

✓ Advantages

  • Common language across teams
  • Framework for threat modeling

⚠ Watch Out

  • Easy to underestimate 'assets' — everything is an asset
Security terminology
1Asset — what you protect (data, a service)
2Vulnerability — a weakness that can be exploited
3Attack — an action that exploits a vulnerability
4Threat — a potential attack
5Control — a defense that reduces risk
6Exposure — possible loss from an attack
🏗️

Security Design Principles

Defense in depth, least privilege, fail securely, minimize attack surface, security by default.
⌄

When to Use

Always — these are design-time decisions that are cheap to get right and expensive to retrofit.

Real-World Example

Least privilege: database user account for your web app should only have SELECT/INSERT — not DROP TABLE.

✓ Advantages

  • Reduces blast radius of breaches
  • Systematic approach

⚠ Watch Out

  • Can conflict with usability
  • Requires upfront discipline
Security design principles
1Defense in depth — multiple security layers
2Least privilege — minimum necessary access
3Fail secure — fail closed, not open
4Minimize attack surface — fewer entry points
5Secure by default — safe out of the box
6Open design — security through algorithms, not obscurity
💉

OWASP Top 10

Top 10 most critical web application security risks. Required knowledge for all developers.
⌄

When to Use

Before building any web application — these are the most exploited vulnerabilities.

Real-World Example

Equifax breach: injection via Apache Struts. 147M records. $700M settlement. OWASP #1 would have prevented it.

✓ Advantages

  • Industry-standard checklist
  • Free resource
  • Covers 95% of real-world attacks

⚠ Watch Out

  • Not exhaustive
  • Top 10 changes over time — check latest version
OWASP Top 10 — the most critical web risks
A01Broken Access Control
A02Cryptographic Failures
A03Injection (SQL, LDAP, OS)
A04Insecure Design
A05Security Misconfiguration
A06Vulnerable Components
A07Identification & Auth Failures
A08Software Integrity Failures
A09Logging & Monitoring Failures
A10Server-Side Request Forgery
🔒

Cryptographic Failures

Storing/transmitting sensitive data without proper encryption. OWASP #2 and one of the most common.
⌄

When to Use

Any time you handle passwords, tokens, PII, financial data.

Real-World Example

LinkedIn 2012: 6.5M password hashes leaked. Stored as unsalted SHA1 — cracked in hours. Should have used bcrypt.

✓ Advantages

  • Easy to fix if caught early
  • Clear best practices exist

⚠ Watch Out

  • Hard to retrofit if architecture is wrong
  • Developers often underestimate what's 'sensitive'
Cryptography — what to avoid vs. what to use
Don't
  • MD5(password)
  • SHA1(password)
  • AES-ECB for data
Do
  • bcrypt / argon2 for passwords
  • AES-256-GCM for data at rest
  • TLS 1.3 for data in transit

📋Quick Reference

θ Ch 13 Cheat Sheet — Security Engineering
Asset
What you're protecting: data, services, reputation.
Vulnerability
A weakness that can be exploited.
Control
Defense: authentication, encryption, validation, monitoring.
Defense in Depth
Multiple security layers — if one fails, others stop the attack.
Least Privilege
Give minimum necessary access. DB account shouldn't have DROP privilege.
OWASP Top 10
Injection, Broken Auth, XSS, IDOR, Security Misconfig, Vulnerable Components... study it.
Bcrypt
Password hashing standard. Slow by design (prevents brute force). Use it, not MD5/SHA1.
HTTPS/TLS
Encrypt data in transit. TLS 1.3 minimum. Free via Let's Encrypt.
θ
Sommerville's Key Points — Ch 13
Author's own summary from the end of the chapter.
  • 1Security is an architectural property — must be designed in, not added later.
  • 2Core concepts: asset, vulnerability, attack, threat, control, exposure.
  • 3Security design: defense in depth, least privilege, fail secure, minimize attack surface.
  • 4OWASP Top 10: the most critical web security risks. Study it.
  • 5Injection attacks (SQL, LDAP): validate all input, use parameterized queries.
  • 6Cryptographic failures: use bcrypt for passwords, AES-256 for data at rest, TLS for transit.
  • 7Security misconfiguration: most common cause of breaches — default passwords, open ports, verbose errors.

🌍From the Book & Beyond

📖

Case Study — The Mentcare Blackmail Scenario

Sommerville's security story for the Mentcare mental-health system reads like a thriller. A criminal learns that a well-paid sports star is receiving treatment for mental health problems and wants illegal access to the records — for blackmail. Mentcare requires passwords of at least eight letters, but never checks their strength. So the attacker poses as a concerned relative, chats with clinic nurses, reads names off their badges, then systematically guesses passwords like the names of the nurses' children. The vulnerability isn't in the code; it's a weak password policy plus human trust. That's why this chapter derives security requirements from risk assessment and misuse cases, not gut feeling.

⚡

2026 Perspective — Supply Chains and Zero Trust

The chapter's layered stack (Figure 13.1) warns that your app inherits vulnerabilities from reusable components — and 2024 proved it spectacularly. In the xz-utils backdoor, an attacker spent years earning maintainer trust in an open-source compression library, then planted a backdoor that nearly shipped inside SSH on major Linux distributions. Modern practice answers with zero-trust architecture — authenticate every request, never assume the internal network is safe — while OWASP's Top 10 keeps evolving beyond injection bugs toward design flaws and supply-chain risk. Sommerville's risk-driven requirements process is exactly how you reason about threats you haven't seen yet.

🧠Quiz — Test Yourself

Think through your answer first, then reveal.

Q1
Recall
What does 'defense in depth' mean? Give a concrete example with 3 layers.
Multiple independent security layers so that if one fails, others prevent the attack. Example: Web app. Layer 1: WAF (blocks known attack patterns). Layer 2: Input validation in app code (blocks injection). Layer 3: Parameterized SQL queries (database-level injection protection). Attacker must break all 3.
Q2
Apply
Why is MD5 not acceptable for password hashing?
MD5 is fast — a GPU can compute billions of MD5 hashes per second. This makes brute-force and rainbow table attacks trivial. Password hashing needs to be SLOW. bcrypt and argon2 are designed to be deliberately slow and computationally expensive, making brute-force attacks impractical even with a leaked database.
Q3
Analyze
What is the 'principle of least privilege' and where should it apply in a typical web app?
Give each component the minimum access needed to do its job. In a web app: App database user: only SELECT/INSERT/UPDATE, not DROP. API keys: scoped to specific operations. User accounts: standard user can't access admin routes. Service accounts: can't access other services' databases. Limits blast radius of any compromise.
Up Next → Week 13
Resilience Engineering
When AWS goes down, your app shouldn't
Continue → Week 13