Security Fundamentals#

flowchart LR
  U([User])
  AUTHN[AuthN<br/>who are you]
  AUTHZ[AuthZ<br/>are you allowed]
  TLS[Transport<br/>TLS / mTLS]
  REST[At rest<br/>KMS, envelope crypto]
  AUDIT[Audit log]
  S[Service]
  U --> AUTHN --> AUTHZ --> S
  S --- TLS
  S --- REST
  S --> AUDIT

  classDef p fill:#dbeafe,stroke:#1e40af,stroke-width:1px,color:#0f172a;
  classDef s fill:#fef3c7,stroke:#92400e,stroke-width:1px,color:#0f172a;
  classDef e fill:#cffafe,stroke:#0e7490,stroke-width:1px,color:#0f172a;
  classDef d fill:#fee2e2,stroke:#991b1b,stroke-width:1px,color:#0f172a;
  classDef o fill:#f3e8ff,stroke:#6b21a8,stroke-width:1px,color:#0f172a;
  class U p;
  class AUTHN,AUTHZ,S s;
  class TLS,REST e;
  class AUDIT o;

    classDef client fill:#dbeafe,stroke:#1e40af,stroke-width:1px,color:#0f172a;
    classDef edge fill:#cffafe,stroke:#0e7490,stroke-width:1px,color:#0f172a;
    classDef service fill:#fef3c7,stroke:#92400e,stroke-width:1px,color:#0f172a;
    classDef datastore fill:#fee2e2,stroke:#991b1b,stroke-width:1px,color:#0f172a;
    classDef cache fill:#fed7aa,stroke:#9a3412,stroke-width:1px,color:#0f172a;
    classDef queue fill:#ede9fe,stroke:#5b21b6,stroke-width:1px,color:#0f172a;
    classDef compute fill:#d1fae5,stroke:#065f46,stroke-width:1px,color:#0f172a;
    classDef storage fill:#e5e7eb,stroke:#374151,stroke-width:1px,color:#0f172a;
    classDef external fill:#fce7f3,stroke:#9d174d,stroke-width:1px,color:#0f172a;
    classDef obs fill:#f3e8ff,stroke:#6b21a8,stroke-width:1px,color:#0f172a;
    class U client;
    class AUTHN,AUTHZ,TLS,REST,S service;
    class AUDIT obs;

Security has five recurring pillars: AuthN (identity), AuthZ (permissions), encryption in transit, encryption at rest, audit. Every system-design answer should be able to address all five.

The five pillars#

flowchart TB
  subgraph AuthN[Identity - AuthN]
    PW[Password + hash<br/>bcrypt / argon2 / scrypt]
    MFA[MFA: TOTP / WebAuthn / SMS-no!]
    SSO[OAuth2 / OIDC / SAML]
    PASS[Passkeys / WebAuthn]
  end
  subgraph AuthZ[Permission - AuthZ]
    RBAC[RBAC]
    ABAC[ABAC]
    REBAC[ReBAC - Zanzibar]
    OPA[OPA / Cedar policies]
  end
  subgraph InTransit[Encryption in transit]
    TLS[TLS 1.3 everywhere]
    MTLS[mTLS service-to-service]
    PIN[Cert pinning - mobile]
  end
  subgraph AtRest[Encryption at rest]
    KMS[KMS - AWS / GCP / Azure]
    ENV[Envelope encryption]
    HSM[HSM for key custody]
    TOKEN[Tokenisation - PAN -> token]
  end
  subgraph Detect[Detect & respond]
    AUDIT[Immutable audit log]
    SIEM[SIEM]
    IDS[Intrusion detection]
  end

  classDef s fill:#fef3c7,stroke:#92400e,stroke-width:1px,color:#0f172a;
  class PW,MFA,SSO,PASS,RBAC,ABAC,REBAC,OPA,TLS,MTLS,PIN,KMS,ENV,HSM,TOKEN,AUDIT,SIEM,IDS s;

    classDef client fill:#dbeafe,stroke:#1e40af,stroke-width:1px,color:#0f172a;
    classDef edge fill:#cffafe,stroke:#0e7490,stroke-width:1px,color:#0f172a;
    classDef service fill:#fef3c7,stroke:#92400e,stroke-width:1px,color:#0f172a;
    classDef datastore fill:#fee2e2,stroke:#991b1b,stroke-width:1px,color:#0f172a;
    classDef cache fill:#fed7aa,stroke:#9a3412,stroke-width:1px,color:#0f172a;
    classDef queue fill:#ede9fe,stroke:#5b21b6,stroke-width:1px,color:#0f172a;
    classDef compute fill:#d1fae5,stroke:#065f46,stroke-width:1px,color:#0f172a;
    classDef storage fill:#e5e7eb,stroke:#374151,stroke-width:1px,color:#0f172a;
    classDef external fill:#fce7f3,stroke:#9d174d,stroke-width:1px,color:#0f172a;
    classDef obs fill:#f3e8ff,stroke:#6b21a8,stroke-width:1px,color:#0f172a;
    class PIN client;
    class PW,MFA,SSO,PASS,RBAC,ABAC,REBAC,OPA,TLS,MTLS,KMS,ENV,HSM,TOKEN,SIEM,IDS service;
    class AUDIT obs;

AuthN - proving identity#

Method	When to use	Notes
Password + hash	last resort	argon2id; never MD5/SHA1; pepper + salt
TOTP (Google Authenticator)	second factor	shared secret + time window
WebAuthn / Passkey	strongest	phishing-resistant, device-bound
SMS OTP	weakest 2FA	SIM swap risk; avoid where possible
OAuth2 / OIDC	federated login	delegate to Google / GitHub / Okta
SAML	enterprise SSO	XML; older but ubiquitous
mTLS	service-to-service	client cert + server cert

AuthZ - what you're allowed to do#

flowchart LR
  REQ[Request + subject]
  POL[Policy engine]
  CTX[Context: resource, action, attrs]
  DEC{Allow?}
  ALLOW[200]
  DENY[403]
  REQ --> POL
  CTX --> POL
  POL --> DEC
  DEC -->|yes| ALLOW
  DEC -->|no| DENY

    classDef client fill:#dbeafe,stroke:#1e40af,stroke-width:1px,color:#0f172a;
    classDef edge fill:#cffafe,stroke:#0e7490,stroke-width:1px,color:#0f172a;
    classDef service fill:#fef3c7,stroke:#92400e,stroke-width:1px,color:#0f172a;
    classDef datastore fill:#fee2e2,stroke:#991b1b,stroke-width:1px,color:#0f172a;
    classDef cache fill:#fed7aa,stroke:#9a3412,stroke-width:1px,color:#0f172a;
    classDef queue fill:#ede9fe,stroke:#5b21b6,stroke-width:1px,color:#0f172a;
    classDef compute fill:#d1fae5,stroke:#065f46,stroke-width:1px,color:#0f172a;
    classDef storage fill:#e5e7eb,stroke:#374151,stroke-width:1px,color:#0f172a;
    classDef external fill:#fce7f3,stroke:#9d174d,stroke-width:1px,color:#0f172a;
    classDef obs fill:#f3e8ff,stroke:#6b21a8,stroke-width:1px,color:#0f172a;
    class REQ,POL,CTX,DEC,ALLOW,DENY service;

Model	Shape	Example
RBAC	(subject) → (role) → (perms)	`user_42 has role 'editor', editor can EDIT`
ABAC	predicate over attributes	`if user.dept == doc.dept && doc.classification ≤ user.clearance`
ReBAC	graph of subject-resource relations	Google Zanzibar / Auth0 FGA
Policy-as-code	rules in OPA / Cedar	declarative, testable

Encryption in transit#

TLS 1.3 only.
HSTS preload for HTTPS-only sites.
mTLS for east-west traffic in a zero-trust mesh.
Cert rotation automated via ACME / SPIFFE / Vault.

Encryption at rest#

Envelope encryption: data encrypted with DEK; DEK encrypted with KEK in KMS.
Per-tenant DEKs to limit blast radius.
Tokenisation for PCI scope (no PAN in app DB).
Always-encrypted columns for sensitive fields.

Secrets management#

Never in env vars or git.
Vault / AWS Secrets Manager / Doppler.
Short-lived dynamic credentials (AWS STS, Vault DB engine).

Threat modelling - STRIDE#

Spoofing identity → authentication.
Tampering with data → integrity, HMAC.
Repudiation → audit logs, signing.
Information disclosure → encryption, RBAC.
Denial of service → rate limiting, WAF, capacity.
Elevation of privilege → least-privilege, defence in depth.

Common headers & defences (web)#

Header / control	Defends against
`Content-Security-Policy`	XSS
`Strict-Transport-Security`	downgrade attacks
`X-Content-Type-Options: nosniff`	MIME sniffing
`Referrer-Policy: strict-origin`	leaking referrers
SameSite cookies	CSRF
Rate limit + bot detection	brute force, scraping
WAF + DDoS scrubbing	layer 7 attacks

Zero-trust posture#

Every service authenticates the caller (mTLS / SPIFFE).
Every action is authorised against policy.
Network position grants no trust.
All access logged + monitored.

Glossary & fundamentals#

Tag	Concept	Page
`HLD`	API gateway (where authn / authz lives at the edge)	api-gateway
`HLD`	Service mesh (mTLS + identity-based authz between services)	service-mesh
`HLD`	HTTP & TLS protocols	http-protocols
`HLD`	Observability (audit + SIEM rely on it)	observability
`LLD`	Error handling (don't leak stack traces)	error-handling

Quick reference#

Interview checklist for every design#

How are users authenticated?
How are services authenticated to each other?
How is access authorised (RBAC / ABAC / ReBAC)?
What's encrypted in transit and at rest?
Where are secrets stored?
What gets logged for audit?
How do we rate-limit and protect against abuse?

Password hashing - what to use today#

argon2id (winner of PHC competition) - preferred.
bcrypt (cost ≥ 12) - acceptable.
scrypt - fine but argon2 is newer.
Never MD5, SHA-1, SHA-256-without-stretching, or unsalted hashes.

OAuth2 / OIDC quick reference#

Authorization Code + PKCE for web + native apps. (Not implicit. Not password.)
Client Credentials for service-to-service.
Access tokens short (5-15 min); refresh tokens longer.
JWTs are convenient but harder to revoke - keep them short or maintain a revocation list.

OWASP Top 10 (must know)#

Broken Access Control
Cryptographic Failures
Injection (SQL, command, LDAP)
Insecure Design
Security Misconfiguration
Vulnerable / Outdated Components
Identification & Authentication Failures
Software & Data Integrity Failures
Security Logging & Monitoring Failures
SSRF

Refs#

OWASP Top 10 → see Further reading.
"Designing for Security" (NIST 800-160).
Google BeyondCorp papers.
Auth0 + Okta engineering blog series.

FAQ#

What is the difference between authentication and authorization?#

Authentication answers who you are, usually via password, MFA, or token. Authorization answers what you are allowed to do, usually via roles, attributes, or policies.

What is mTLS and when should I use it?#

Mutual TLS authenticates both sides of a connection with certificates. Use it for service-to-service traffic in a zero-trust network where you cannot rely on the network perimeter.

How does envelope encryption work?#

A data key encrypts each blob and a master key in KMS encrypts the data key. Rotating the master key is cheap, and the cleartext data key only lives in memory during use.

What are the OWASP Top 10?#

A list of the most critical web application security risks like injection, broken access control, and cryptographic failures. It is the baseline checklist for any security review.

Should authentication ever happen at the edge?#

Yes. The API gateway or service mesh can terminate tokens and pass a verified identity header inward, but services must still enforce authorization on their own data.

API Gateway: API gateways enforce authentication, authorization, and TLS termination as the security perimeter
HTTP Protocols: HTTPS, TLS, and HTTP security headers are the foundational mechanisms of web security
Service Mesh: service meshes provide mTLS and zero-trust security for internal service-to-service communication