Security
Security is not a feature you add at the end. It is a property of how you think about every line of code, every API boundary, every deployment pipeline, and every human process in your organization. Most breaches don't come from exotic zero-days — they come from an engineer who hardcoded a database password, a forgotten admin endpoint with no authentication, or a JWT implementation that doesn't validate the algorithm header.
This section teaches you to think like an attacker so you can build like a defender. Every vulnerability is shown with both the exploitable code and the fixed version, because understanding why something is vulnerable matters more than memorizing a checklist.
Thinking in Threat Models
Before you can defend a system, you need to understand what you are defending it against. Threat modeling is the practice of systematically asking: what can go wrong?
A simple threat model for any system follows these four steps:
Step 1 — What are we building? Draw a data flow diagram. Identify every entry point, data store, trust boundary, and external dependency. You cannot secure what you cannot see.
Step 2 — What can go wrong? Use the STRIDE framework: Spoofing (can someone pretend to be someone else?), Tampering (can someone modify data in transit or at rest?), Repudiation (can someone deny they did something?), Information disclosure (can someone see data they shouldn't?), Denial of service (can someone make the system unavailable?), Elevation of privilege (can someone gain access they shouldn't have?).
Step 3 — What are we doing about it? For each threat, you either mitigate it (apply a control), accept it (document why), transfer it (insurance, third-party service), or eliminate it (remove the feature).
Step 4 — Did we do a good job? Review, test, pentest, and repeat. Threat models are living documents.
Learning Path
Build security knowledge in this order — each layer depends on the previous one:
| Order | Subsection | What You'll Learn | Threat Category |
|---|---|---|---|
| 1 | OWASP Top 10 (2021) | The ten most critical web application security risks, each with exploit demos and fixes. Start here for threat context. | All categories |
| 2 | Encryption | Symmetric vs asymmetric, TLS 1.3 handshake, hashing, key derivation, at-rest and in-transit. Foundation for everything else. | Information Disclosure, Tampering |
| 3 | Authentication | JWT internals byte-by-byte, OAuth2/OIDC flows, session management, MFA, passkeys | Spoofing, Elevation of Privilege |
| 4 | Authorization | RBAC, ABAC, Zanzibar-style ReBAC, policy engines (OPA), permission systems at scale | Elevation of Privilege |
| 5 | Secrets Management | Vault, AWS Secrets Manager, env var anti-patterns, rotation strategies, CI/CD secrets | Information Disclosure |
| 6 | Zero Trust | Network segmentation, identity-based access, mTLS, BeyondCorp model, policy engines | All categories |
| 7 | API Security | Rate limiting, input validation, CORS, CSRF, API key management, GraphQL-specific risks | Tampering, DoS, Information Disclosure |
| 8 | Exploits & Vulnerabilities | Log4Shell, Heartbleed, XZ Backdoor — attack techniques for defensive understanding | All categories |
Security Principles
Six principles underpin everything in this section:
- Defense in depth — No single control is sufficient. Layer your defenses so that a failure in one layer does not mean a total breach.
- Least privilege — Every user, service, and process should have the minimum permissions required to do its job, and nothing more.
- Fail secure — When something breaks, it should deny access by default, not grant it.
- Zero trust — Never trust, always verify. Authenticate and authorize every request regardless of network origin.
- Secrets are toxic — Every secret you store is a liability. Minimize them, rotate them, and never put them in source code.
- Assume breach — Design your systems so that when (not if) an attacker gets in, the blast radius is contained.
Start with the OWASP Top 10 for a practical survey of what goes wrong most often, then work through authentication and encryption for the fundamental building blocks, and finish with zero trust and API security to tie it all together at the architectural level.