Security: HTTPS, Encryption, Zero Trust & OWASP Top 10

Security isn’t a feature you bolt on at the end — it’s a property of every layer. A senior is expected to reason about the primitives (TLS, crypto, hashing), recognize the common vulnerability classes (OWASP Top 10), and apply defense in depth: no single control is trusted to be enough. This builds on auth & authz (who you are and what you can do) and wraps the API surface.

TLS / HTTPS: how the handshake actually works

HTTPS is HTTP over TLS. TLS gives you three things: encryption (eavesdroppers see ciphertext), integrity (tampering is detected), and authentication (you’re talking to the real server, not a man-in-the-middle).

The clever part is combining slow asymmetric crypto with fast symmetric crypto:

1. ClientHello — client offers TLS versions and cipher suites.
2. Certificate — server sends its X.509 cert containing its public key, signed by a Certificate Authority (CA). The client validates the signature chain up to a trusted root.
3. Key exchange — client and server use asymmetric crypto (ECDHE) to agree on a shared symmetric session key that no eavesdropper can derive.
4. Symmetric encryption — the rest of the session uses fast AES with that session key.

So asymmetric crypto is used once to bootstrap trust and exchange a key; symmetric crypto does the bulk work. A certificate proves identity (this public key belongs to bank.com, vouched for by a CA) — it does not prove the site is safe or honest.

mTLS (mutual TLS) adds a second cert: the client also presents one, so both sides authenticate. This is the standard for service-to-service auth inside a Zero Trust mesh — every call proves identity cryptographically, not by IP.

Crypto fundamentals (and the confusion to avoid)

The single most common interview confusion: Base64 is not encryption. Encoding is reversible by anyone with no key — it hides nothing.

• Symmetric (AES) — one shared key encrypts and decrypts. Fast; the hard part is sharing the key securely.
• Asymmetric (RSA / ECC) — a public/private keypair. Encrypt with public, decrypt with private; or sign with private, verify with public. Slow, so used for key exchange and signatures, not bulk data.
• Digital signature — sign a hash of the message with your private key; anyone verifies with your public key. Proves authenticity + integrity.
• In transit vs at rest — TLS protects data in transit; disk/DB encryption (AES via KMS) protects it at rest. You need both — encrypting only one leaves a gap.

Password storage: never plaintext, never fast

Passwords must never be stored in plaintext, and never with fast general-purpose hashes (MD5, SHA-1, raw SHA-256) — a GPU computes billions of those per second.

Use a salted, slow, adaptive hash: bcrypt, scrypt, or argon2id (the current OWASP recommendation).

• Salt — a unique random value per user, stored alongside the hash. Defeats rainbow tables (precomputed hash lookups) and ensures two users with the same password get different hashes.
• Slow / work factor — tunable cost makes each guess expensive, defeating offline brute force. Raise the cost as hardware improves.
• Pepper — an optional secret added before hashing, stored separately (e.g. in a KMS, not the DB), so a DB-only leak still can’t be cracked.

# WRONG — fast hash, no salt, crackable in seconds
hash = sha256(password)

# RIGHT — argon2id: salted, slow, memory-hard
from argon2 import PasswordHasher
ph = PasswordHasher()              # tunable time/memory/parallelism cost
stored = ph.hash(password)         # salt is generated and embedded
ph.verify(stored, login_attempt)   # constant-time compare

Secrets management

Hardcoded secrets are a top breach cause. The rules:

• No secrets in code or in committed .env files — they live in git history forever once pushed.
• Use a secrets manager — HashiCorp Vault, cloud KMS (AWS KMS, GCP KMS), or sealed secrets in Kubernetes. The app fetches secrets at runtime with a short-lived identity.
• Rotate credentials regularly and immediately on suspected compromise; prefer short-lived, auto-rotating credentials over long-lived static keys.
• Least-privilege IAM — each service gets only the permissions it needs, scoped to specific resources. A leaked credential then has a tiny blast radius.

OWASP Top 10 (2021): the canonical vulnerability list

This is the most cited security checklist in interviews. Know each class and a one-line mitigation:

Broken Access Control is the #1 category — and IDOR (Insecure Direct Object Reference) is the classic: GET /orders/124 returns someone else’s order because the server checks authentication but not ownership. Fix: scope every query to the authenticated principal.

Injection — the textbook SQLi, and the fix:

# VULNERABLE — string concatenation; input "' OR '1'='1" dumps the table
db.execute("SELECT * FROM users WHERE email = '" + email + "'")

# SAFE — parameterized query; the driver binds input as data, never code
db.execute("SELECT * FROM users WHERE email = %s", (email,))

The same principle covers command injection (use arg arrays, not shell strings) and NoSQL injection. The rule: separate code from data — never let user input become executable.

XSS, CSRF, and brute-force protection

XSS (Cross-Site Scripting) — attacker injects script that runs in another user’s browser:

• Stored — malicious input saved server-side, served to every viewer.
• Reflected — script bounced back from a request parameter.
• DOM-based — client-side JS writes untrusted data into the page.

Mitigations: output encoding (escape data for the context it lands in — HTML, attribute, JS), a strict Content Security Policy (CSP) to block inline/foreign scripts, and allowlist input validation (accept known-good, reject the rest — never just blocklist).

CSRF (Cross-Site Request Forgery) — a malicious site tricks the victim’s browser into making an authenticated request using their cookies. Mitigations: SameSite cookies (Strict/Lax), anti-CSRF tokens (unpredictable per-form token the attacker can’t read), and checking Origin/Referer.

Brute force / credential stuffing — rate-limit login and OTP endpoints (per-IP and per-account), add exponential backoff and lockouts, CAPTCHA on suspicious patterns, and require MFA. (More in auth & authz.)

Zero Trust: from castle-and-moat to “never trust, always verify”

The old perimeter model (“castle-and-moat”) trusted anything inside the network — once past the firewall, services talked freely. One breached host then owned the whole flat network.

Zero Trust assumes the network is already hostile. Its principles (NIST SP 800-207):

• Never trust, always verify — no implicit trust from network location; verify every request.
• Verify explicitly — authenticate and authorize on identity, device posture, and context, every time.
• Least privilege — minimal access, just-in-time, for the specific resource.
• Assume breach — design as if an attacker is already inside; limit blast radius.
• Microsegmentation — fine-grained network zones so a compromised service can’t reach everything.
• mTLS everywhere — services prove identity to each other cryptographically, not by IP. This is where the service mesh lives — see distributed systems.

The throughline across all of it: defense in depth (layered controls), secure-by-default (the safe path is the easy path), and allowlist input validation at every boundary.

Interview questions & model answers

Q: Walk me through the TLS handshake. “The client sends a hello, the server returns its certificate with a public key signed by a CA, and the client validates that chain. Then they use asymmetric crypto — ECDHE — to agree on a shared symmetric session key without an eavesdropper learning it. The rest of the session uses fast symmetric AES with that key. So asymmetric bootstraps trust and exchanges a key once; symmetric does the bulk encryption. TLS 1.3 cuts this to one round trip and removes legacy weak crypto.”

Q: How do you store user passwords? “Never plaintext, and never a fast hash like MD5 or SHA-256 — GPUs crack those in bulk. I use a salted, slow, adaptive hash: argon2id, bcrypt, or scrypt. The per-user salt defeats rainbow tables and makes identical passwords hash differently; the tunable work factor makes brute force expensive and can be raised as hardware improves. Optionally a pepper — a secret stored separately from the DB — so a database-only leak still can’t be cracked.”

Q: Hashing vs encryption vs encoding? “Encoding like Base64 is reversible by anyone with no key — it’s for transport, not security. Hashing is one-way: you can’t recover the input, used for integrity and password storage. Encryption is reversible but only with the key, used for confidentiality. The common mistake is treating Base64 as if it hides anything — it doesn’t.”

Q: How do you prevent SQL injection? “Parameterized queries — prepared statements where the driver binds user input as data, never as part of the SQL string. Never concatenate input into a query. Same principle for command injection: pass arguments as an array, not a shell string. The rule is to keep code and data separate so input can never become executable. Defense in depth adds least-privilege DB accounts and input validation.”

Q: XSS vs CSRF? “XSS is injecting script that runs in another user’s browser — fixed with output encoding, a Content Security Policy, and input validation. CSRF tricks a logged-in user’s browser into making a request with their cookies — fixed with SameSite cookies and anti-CSRF tokens. XSS abuses trust the user has in the site; CSRF abuses trust the site has in the user’s browser.”

Q: What is Zero Trust? “Never trust, always verify. The old model trusted everything inside the network perimeter; Zero Trust assumes the network is already compromised and verifies every request explicitly on identity and context, grants least privilege just-in-time, and assumes breach by microsegmenting so one compromised service can’t reach everything. In practice that’s mTLS between services, per-request authz, and short-lived credentials.”

Q: How do you protect a login endpoint from brute force? “Rate-limit per IP and per account, exponential backoff and temporary lockouts, CAPTCHA on anomalies, and slow password hashes so each guess is expensive. Require MFA so a cracked password alone isn’t enough, and monitor for credential-stuffing patterns.”

Common mistakes / what weak candidates do

• Calling Base64 encryption — confusing encoding with security.
• Storing passwords with MD5/SHA-1 or no salt — crackable in seconds with a rainbow table or GPU.
• String-concatenating SQL instead of parameterized queries — the classic injection.
• Checking authentication but not authorization — IDOR, returning other users’ data by ID.
• Hardcoding secrets in code or committing .env to git — leaked forever in history.
• Trusting the network perimeter — assuming “internal” traffic is safe; no mTLS or per-request authz.
• Encrypting in transit but not at rest (or vice versa) — leaving one half of the data exposed.
• Blocklist input validation — trying to enumerate bad input instead of allowlisting good.
• No logging or monitoring of security events — breaches go undetected for months.
• Treating security as a final checklist instead of defense in depth across every layer.