Security Knowledge Base
Security is not a feature you add at the end β it's a property you design in from the start.
Why Security Matters for Engineers
Security vulnerabilities are almost always caused by engineering decisions, not bad luck:
- A parameterized query prevents SQL injection
- An HttpOnly cookie flag prevents XSS-based session theft
- A short JWT expiry limits the blast radius of a token leak
- A GDPR-compliant erasure flow protects users and avoids β¬20M fines
You don't need to be a security specialist. You need to know enough to write safe code and enough to ask the right questions in a design review.
What's Covered
| Topic | Description |
|---|---|
| Authentication & Authorization | Sessions, JWT, OAuth 2.0, OIDC, MFA, RBAC, ABAC, passkeys |
| Web Vulnerabilities & Defenses | OWASP Top 10 β SQL injection, XSS, CSRF, SSRF, IDOR and mitigations |
| Cryptography & Secure Design | AES-GCM, RSA, HMAC, signatures, TLS internals, key management |
| Privacy & Compliance | GDPR, CCPA, PCI-DSS, HIPAA, data classification, right to erasure |
| Network Security | Firewalls, WAF, DDoS, DNS security, zero trust, mTLS |
| Secure SDLC & DevSecOps | Threat modeling, SAST, DAST, SCA, secrets scanning, container security |
| Identity & Access Management | SSO, SAML, LDAP, service accounts, Vault, JIT access, cloud IAM |
| API Security | OWASP API Top 10, input validation, rate limiting, GraphQL security |
| Incident Response | IR lifecycle, detection, containment, recovery, post-mortem |
| Interview Questions | 21 deep-dive answers + quick-fire reference table |
Security Mental Model
Think of security in layers β every layer can fail, so you never rely on just one. Click any layer below to inspect its technologies, threats, and design principles.
Security Mental Model β Defence in DepthClick a layer to inspect
PERIMETER
WAFDDoS ProtectionFirewallCDN Edge Rules
TRANSPORT
TLS 1.3mTLSCertificate ManagementHSTS
IDENTITY
AuthN / OAuth 2.0MFA / PasskeysSSO / SAML / OIDCToken Rotation
APPLICATION
AuthZ / RBAC / ABACInput ValidationOWASP ControlsCSP / CORS
DATA
AES-256-GCM at restField-level maskingPII tokenisationKey Management (Vault)
AUDIT
Immutable LogsSIEM / AlertingAnomaly DetectionForensic Trails
Attackers always find the weakest layer β every layer must hold independently
Select a layer to inspect
Technologies, threats, and design principles
Attackers always find the weakest layer. Defence in depth means there is no single point of failure.
The OWASP Top 10 at a Glance
| # | Risk | One-Line Fix |
|---|---|---|
| A01 | Broken Access Control | Always verify ownership server-side |
| A02 | Cryptographic Failures | AES-256-GCM at rest, TLS in transit |
| A03 | Injection (SQL, Command) | Parameterized queries, never concatenate |
| A04 | Insecure Design | Threat model before you build |
| A05 | Security Misconfiguration | Disable defaults, no verbose errors |
| A06 | Vulnerable Components | SCA scan in CI, auto-update patches |
| A07 | Auth Failures | MFA, short tokens, account lockout |
| A08 | Integrity Failures | Never deserialize untrusted data |
| A09 | Logging Failures | Log every auth event, no PII in logs |
| A10 | SSRF | Block private IPs, allowlist domains |
Key Security Principles
| Principle | In Practice |
|---|---|
| Least Privilege | Grant only the minimum permissions needed β to users, services, and DB accounts alike |
| Defense in Depth | Assume every control can fail; never rely on a single layer |
| Fail Secure | Default to deny; errors should lock down, not open up |
| Don't Roll Your Own Crypto | Use BCrypt, AES-GCM, TLS 1.3 β not home-grown algorithms |
| Secure by Default | Secure configuration out of the box, not opt-in |
| Minimize Attack Surface | Every unused endpoint, port, and dependency is a liability |
| Assume Breach | Design so that a compromised component limits blast radius |
| Zero Trust | Verify every request β network location is not a trust boundary |
Common Vulnerabilities by Layer
Code Level
- SQL / NoSQL / Command injection
- XSS (Stored, Reflected, DOM)
- Insecure deserialization
- Hardcoded secrets
Authentication / Session
- Weak passwords, no MFA
- Token leakage (logging, error messages)
- Session fixation, no logout invalidation
- JWT
alg: noneacceptance
Authorization
- IDOR (Insecure Direct Object Reference)
- Privilege escalation via mass assignment
- Missing function-level authorization
- Overly broad IAM permissions
Infrastructure
- Misconfigured cloud storage (public S3 buckets)
- Exposed admin endpoints (Actuator, Swagger)
- Unencrypted data at rest
- Outdated dependencies with CVEs
Learning Path
For Interview Preparation
- Authentication & Authorization β most common interview topic
- Web Vulnerabilities β OWASP Top 10 is expected knowledge
- Cryptography β hashing vs encryption, TLS basics
- Privacy & Compliance β GDPR basics, PCI-DSS rules
- Interview Questions β practise with answers
For Production Systems
- Start with Secure SDLC β embed security early
- API Security β your primary attack surface
- IAM β get service identities right
- Incident Response β prepare before you need it
For Compliance Projects
- Privacy & Compliance β regulatory requirements
- Cryptography β encryption obligations
- Audit Logging β evidence trail
- Network Security β infrastructure controls
Quick Reference: Technology Choices
| Need | Recommended |
|---|---|
| Password hashing | Argon2id (best) Β· BCrypt (standard) |
| Symmetric encryption | AES-256-GCM |
| Asymmetric encryption / signing | RS256 / ES256 (JWT), RSA-OAEP (encryption) |
| TLS | TLS 1.3 (minimum TLS 1.2) |
| Token format | JWT (RS256) + short TTL + refresh rotation |
| SSO protocol (enterprise) | SAML 2.0 or OIDC |
| SSO protocol (consumer) | OAuth 2.0 + OIDC |
| Secrets management | HashiCorp Vault Β· AWS Secrets Manager |
| SAST (Java) | SpotBugs + Find Security Bugs Β· SonarQube |
| Dependency scanning | OWASP Dependency-Check Β· Snyk |
| Secrets scanning | Gitleaks |
| Container scanning | Trivy |
| DAST | OWASP ZAP |
| WAF | AWS WAF Β· Cloudflare Β· nginx ModSecurity |
Interview tip
Security questions in system design interviews almost always touch one of three areas: how do you authenticate/authorize, how do you protect sensitive data, and what do you do when something goes wrong. Make sure you can answer all three confidently.
Never do this
- Store passwords in plaintext or MD5
- Concatenate user input into SQL queries
- Commit secrets to version control
- Return stack traces in API error responses
- Trust the
user_idsent by the client β always derive it from the validated token