Security, privacy, compliance

A) AuthN/AuthZ & service-to-service auth

Say

“Authentication is identity; authorization is permission. We enforce at the gateway and in the service (defense in depth).”

Core concepts

AuthN: who the caller is (user/app/service).
AuthZ: what actions are allowed (scope/role/policy + resource checks).
Least privilege: narrow scopes, short-lived credentials, auditable decisions.

Auth stack — template

Template

Users (web/mobile): • OIDC (OAuth2 Auth Code + PKCE) • Short-lived access token (minutes) + rotating refresh token • Phishing-resistant MFA (WebAuthn/passkeys) for sensitive flows Services: • mTLS (service identity) + per-request authZ policy • Or OAuth2 Client Credentials for service tokens (short TTL) AuthZ models: • RBAC (roles) for coarse permissions • ABAC (attributes like tenant/region/risk) • ReBAC (relationship/graph: follower, member, owner) Critical validation: • Validate iss, aud, exp/nbf (clock skew), signature, and scope/permissions • Never trust identity headers unless injected by a trusted gateway

Facebook-like Home Feed — Auth design

Example

• Gateway validates JWT for GET /v1/feed and write endpoints. • Feed service re-checks authorization for privacy (blocks, private accounts). • Internal hops: mTLS identity between API Gateway ↔ Feed Service ↔ Graph Service. • Step-up auth (WebAuthn) for account recovery or changing email/password.

Pitfalls

Long-lived tokens with no revocation plan
Skipping audience (aud) checks or trusting any issuer
Bearer tokens in logs/traces
Using localStorage for tokens in browsers (XSS risk)
No CSRF protection when using cookies for sessions

↑ Back to top

B) Secrets management & rotation

Say

“Secrets live in a central manager, delivered just-in-time, and rotated automatically with audit trails.”

What counts as a secret

API keys, DB creds, signing keys, private keys, OAuth client secrets, webhook secrets.
Also: “secret-like” values (connection strings, internal endpoints, salt/pepper).

Secrets program — template

Template

Storage: • Use a managed secret store (Vault / AWS Secrets Manager / GCP Secret Manager) • Encrypt at rest; strict IAM; every access audited Delivery: • Do NOT bake into images or repos • Pull at startup via short-lived identity; or sidecar agent • Minimize exposure: avoid env var dumps; redact logs Rotation: • TLS certificates: ≤ 90 days (automated) • DB creds: dynamic/leased creds when possible • API keys: 30–90 days; support key overlap during rotation • Signing keys: key sets (kid) + rollout/rollback plan Break-glass: • Strongly controlled emergency access (hardware keys), time-bound and audited

Facebook-like Home Feed — secrets in practice

Example

• API Gateway uses rotated JWT verification keys via JWKS caching. • Feed/Graph services use dynamic DB creds (leased) and auto-rotated mTLS certs. • Moderation webhooks use per-integration secrets; rotation supports overlap windows.

Pitfalls

Hard-coding a “secret zero” (initial root key) in config
No rotation runbook (keys never change)
Secrets leaking into logs, crash dumps, or analytics
Storing secrets in CI variables without access controls/audit

↑ Back to top

C) Encryption in transit & at rest — envelope encryption

Say

“TLS everywhere, and for sensitive fields we use envelope encryption so keys can rotate without rewriting all data.”

What to encrypt

In transit: TLS 1.2+ at the edge; mTLS internally where appropriate.
At rest: disk/volume encryption + app-level encryption for high-sensitivity fields.
Backups: encrypted + immutable storage (WORM) + access logging.

Envelope encryption — template (pseudocode)

Template

# CMK (KMS/HSM key) never leaves the service boundary
dek_plain, dek_wrapped = KMS.generate_data_key(CMK)

ciphertext = AEAD.encrypt(plaintext, dek_plain, aad=metadata)

store({
  "ciphertext": ciphertext,
  "dek_wrapped": dek_wrapped,
  "alg": "AES-256-GCM",
  "key_id": "cmk_123"
})

# Rotation: re-wrap DEKs with a new CMK without re-encrypting the data

Facebook-like Home Feed — encryption choices

Example

• TLS for all external endpoints; mTLS for service-to-service. • Encrypt sensitive fields like email/phone in user profile with envelope encryption. • Analytics receives only redacted or tokenized identifiers (no raw PII).

Pitfalls

One global key for everything (blast radius + rotation pain)
Plaintext temp files or debug dumps containing sensitive fields
No audit of decrypt operations
Sending raw PII into logs/analytics pipelines

↑ Back to top

D) PII handling: minimization, retention & RTBF (deletion)

Say

“Privacy is an engineering workflow: classify → minimize → retain only what’s needed → delete reliably.”

PII lifecycle

Classify: tag fields at ingest (Public / Internal / Sensitive / Restricted).
Minimize: collect only what is necessary; reduce copies; avoid exporting raw PII.
Retention: explicit time limits per dataset; automated TTL where possible.
RTBF deletion: delete in DB + propagate to cache, search, logs, analytics; backups expire per policy (and are not “restored into production” without deletion replay).

RTBF deletion pipeline — template

Template

1) Identify subject (user_id / stable identity key) 2) Emit deletion event (versioned): user.delete.requested 3) Fanout workers purge: • primary DB rows + indexes • caches (tenant-aware keys) • search documents • analytics tables (if required) or enforce TTL 4) Verify (queries + audit evidence) 5) Backups: expire per retention; if restored, reapply deletion events 6) Produce completion record / certificate

Facebook-like Home Feed — PII & deletion

Example

• User profile includes: email/phone + privacy controls. • Logs store request_id and user_id (hashed/tokenized where possible), not raw email/phone. • Deleting an account purges: - profile records - feed materialization references - search index docs (username) - caches + CDN variants - moderation/report links per policy

Pitfalls

Forgetting caches and search indexes during deletion
PII in logs/traces, support tickets, or crash dumps
Indefinite retention “just in case”
Treating hashing as anonymization without considering re-identification risk

↑ Back to top

E) Abuse prevention: WAF, bot controls, spam/fraud signals

Say

“We defend at multiple layers: edge WAF + rate limits, then behavior/risk scoring, then step-up controls.”

Defense layers

Edge: WAF rules, DDoS protection, token-bucket rate limits, geo/IP reputation.
Application: device fingerprinting (privacy-aware), anomaly detection, velocity rules, content filtering.
User safety: reporting flows, moderation queues, appeals, shadow bans where appropriate.

Abuse controls — template

Template

• Rate limit at gateway (per user/app/IP) with 429 + Retry-After • Challenge on suspicion: CAPTCHA / proof-of-work / email or phone verification • Spam & fraud detection: velocity limits, reputation scores, risky geo patterns • Content safety: ML + rules + human review, plus audit trails and appeals • Protect writes more than reads; cost-weighted quotas (write=5, read=1)

Facebook-like Home Feed — abuse controls

Example

• Like/comment endpoints are more strictly rate-limited than GET /v1/feed. • Suspicious accounts trigger step-up verification before posting. • Reports endpoint (POST /v1/content/{content_id}/reports) has abuse throttles + moderation triage queues.

Pitfalls

Relying only on IP blocking (easy to bypass, harms shared networks)
Blanket CAPTCHAs that kill UX
No replay protection for webhooks or write operations
No audit trail for moderation actions

↑ Back to top

F) Compliance: GDPR/CCPA, PCI (practical engineering view)

Say

“Compliance becomes implementable when you translate it into: data map, retention, DSAR workflows, and incident runbooks.”

GDPR / CCPA (operational)

DSAR: access/export, correction, deletion (RTBF), portability.
Vendor risk: DPAs, subprocessors, least-privileged access, audit logs.
Cross-border/data residency: region pinning + contractual controls.
Breach readiness: detection + triage + comms runbook.

PCI (payments)

Minimize scope: hosted payment fields/pages from a compliant provider.
Avoid storing PAN/CVV; tokenize and store only last4 + brand when needed.

Facebook-like Home Feed — compliance mapping

Example

• GDPR/CCPA: deletion pipeline covers profile, feed caches, search docs, and analytics per policy. • Vendor DPAs: moderation vendors and analytics platforms are audited and access-controlled. • If payments exist (subscriptions): use hosted checkout, keep the feed system out of PCI scope.

Pitfalls

Assuming legal will ‘handle it’ without engineering workflows
Accidentally storing payment data (PAN/CVV) in logs
No DSAR tooling or runbooks (manual, slow, inconsistent)
Data residency requirements not reflected in routing/storage design

↑ Back to top

G) Operational guardrails (audit, monitoring, incident response)

Say

“Security controls need monitoring: audit logs, anomaly alerts, and tested incident response.”

Security operations — template

Template

Audit logs: • Auth events (login, MFA changes), privilege changes, key usage (KMS decrypt), policy updates Detection: • WAF spikes, unusual auth failures, token anomalies, secret access bursts, impossible travel patterns Response: • Break-glass access (hardware keys), rotating credentials, token revocation / session purge • Incident roles + comms template + postmortem actions with owners & dates

Facebook-like Home Feed — monitoring & response

Example

• Alerts on abnormal login failures and unusual report/like velocity. • KMS decrypt spikes trigger investigation (possible data exfil attempt). • “Disable posting” kill switch for emergencies while keeping GET /v1/feed available.

↑ Back to top

H) Quick checklists (fast interview answers)

AuthN/AuthZ

OIDC (PKCE) for users
Short-lived tokens + rotation
mTLS for services
RBAC/ABAC/ReBAC as needed

Secrets & keys

Central manager + audit
Automated rotation (certs ≤ 90d)
Envelope encryption for sensitive fields

Privacy

Classify → minimize → retain
RTBF pipeline to caches/search/analytics
Redact logs/traces

Abuse

WAF + token buckets
Risk scoring + step-up controls
Moderation workflow + audit

Facebook-like Home Feed — checklist summary

Example

• Short-lived JWTs at edge; mTLS inside; privacy checks in service. • Secrets via manager + rotation; envelope encrypt sensitive profile fields. • Delete reliably across DB + cache + search + analytics + backups policy. • Rate-limit writes + moderation workflow for reports/spam.

↑ Back to top

I) Sample snippets (copy/paste friendly)

JWT claims — template (example payload)

Template

{
  "iss": "https://idp.example.com",
  "sub": "user_123",
  "aud": "feed-api",
  "scope": "feed:read posts:write",
  "jti": "9f9d7c3a-0a6e-4e5b-b18e-6c3f25a1e1df",
  "iat": 1731080000,
  "exp": 1731081800
}

Cookie flags — template (browser sessions)

Template

Set-Cookie: sid=...; HttpOnly; Secure; SameSite=Lax; Path=/; Max-Age=1800

CSP starter — template

Template

Content-Security-Policy:
  default-src 'self';
  script-src 'self' 'nonce-<random>';
  object-src 'none';
  frame-ancestors 'none';
  base-uri 'self';

Webhook verification — template

Template

# Verify signature to prevent spoofing/replay
sig = HMAC_SHA256(secret, raw_body)
if !constant_time_equals(sig, request.headers["X-Signature"]):
  reject(401)

# Add replay protection (timestamp + nonce) for high-risk callbacks

Facebook-like Home Feed — snippet placement

Example

• Webhooks for moderation callbacks use HMAC verification + replay protection. • JWT validation enforces iss/aud/exp; request_id used for audit correlation. • CSP protects the web UI against script injection.

↑ Back to top

J) One-liners (ready for interviews)

“Least privilege + short-lived tokens; step-up auth for sensitive actions.”
“Gateway validates identity; services enforce resource-level authorization.”
“mTLS for service identity; never trust identity headers from untrusted hops.”
“Envelope encryption: DEK per object, wrapped by CMK; decrypt calls are audited.”
“Privacy is a pipeline: classify → minimize → retain → delete across DB/cache/search/analytics.”
“WAF + rate limits at edge; risk scoring and moderation workflow for abuse.”
“We reduce PCI scope via hosted payments; DSAR/RTBF is operationalized via APIs and runbooks.”

↑ Back to top