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
Asset: what you protect (data, service) Vulnerability: weakness that can be exploited Attack: action that exploits vulnerability Threat: potential attack Control: defense that reduces risk Exposure: possible loss from 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
1. Defense in depth: multiple security layers 2. Least privilege: minimum necessary access 3. Fail secure: fail closed, not open 4. Minimize attack surface: fewer entry points 5. Security by default: secure out of the box 6. Open 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
A01: Broken Access Control A02: Cryptographic Failures A03: Injection (SQL, LDAP, OS) A04: Insecure Design A05: Security Misconfiguration A06: Vulnerable Components A07: Identification/Auth Failures A08: Software Integrity Failures A09: Logging/Monitoring Failures A10: SSRF
🔒

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'
❌ Wrong: MD5(password) ❌ Wrong: SHA1(password) ❌ Wrong: AES-ECB for encrypted data ✓ Right: bcrypt/argon2 for passwords ✓ Right: AES-256-GCM for data at rest ✓ Right: 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.

🧠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