Web Server, API, and Cloud/Container Security
Core concepts
Know server hardening: minimal installed services, patched components, least-privilege service accounts, disabled directory listing and default pages, TLS configuration with modern ciphers, security headers (HSTS, CSP, X-Content-Type-Options, frame options), and safe error pages. Understand reverse proxies and load balancers as trust boundaries: forwarded headers must be set by the proxy, not the client.
API security
Know the OWASP API risks: broken object-level authorization (BOLA), broken authentication, excessive data exposure, mass assignment, rate limiting, and improper inventory. Every object reference must be authorized; responses should return only necessary fields; schemas should reject unexpected properties. Know API keys vs OAuth tokens, mTLS for service-to-service, and gateway throttling.
Cloud and containers
Understand shared responsibility, IAM least privilege, avoiding public buckets, secret managers, and metadata-service protections (SSRF to cloud metadata is a classic escalation). For containers: minimal base images, non-root users, read-only filesystems, image scanning, signed images, and no secrets baked into layers. Know Kubernetes basics: RBAC, network policies, secrets, and pod security standards.
Traps
Questions assume the cloud provider secures application data, or that a private bucket is safe when IAM is wildcarded. Another trap: trusting client-supplied X-Forwarded-For or failing to restrict metadata endpoints.
Rule of thumb
Every object reference is authorized; every workload runs as non-root with least-privilege identity.
Worked example
An API returns full user records. Fix by shaping responses to required fields and enforcing object-level authorization, not by hiding fields in the UI.