API Security, Authentication and Authorization Questions

Controlling who can call an API, what they may do, and defending it against abuse. Covers the access-control mechanics: API keys, OAuth 2.0 flows, OpenID Connect, JWT issuance/validation, session vs. token auth, scopes/roles for fine-grained authorization, token lifetime and refresh, mutual TLS, and machine-to-machine vs. user-delegated access. Also covers the adversarial hardening view: input validation, injection and deserialization risks, broken object-level authorization (BOLA), mass assignment, secrets handling, and the OWASP API Security Top 10, plus securing data in transit, preventing enumeration/scraping, and testing APIs for vulnerabilities.

EasyTechnical

52 practiced

Walk me through mutual TLS (mTLS): how does the handshake differ from standard one-way TLS, how do the client and server present and verify each other's certificates, and what are the practical options for certificate provisioning and rotation for service-to-service authentication in a microservice or service-mesh deployment?

Sample Answer

MediumTechnical

101 practiced

Describe a secure key management and rotation architecture for API signing and encryption keys. Cover the roles of HSM/KMS vs Vault, envelope encryption, automated rotation schedules, key versioning, secure provisioning to services, access control policies, and rollback strategies if a key is compromised.

Sample Answer

HardSystem Design

58 practiced

Architect a security model for a large-scale microservices platform (~1000 services) that uses a service mesh (e.g., Envoy/Istio) and an API gateway. Goals: enforce strong service-to-service authentication and authorization, minimize blast radius, centralize policy where sensible but avoid bottlenecks, ensure observability and incident response. Provide key components, identity model, policy enforcement points, rollout plan and scaling considerations.

Sample Answer

Direct answer At roughly 1,000 services, service-to-service authentication and authorization has to be enforced by infrastructure (a service mesh sidecar, such as Envoy, paired with a control plane like Istio) rather than by each service's own application code, because you cannot reliably audit or update security logic duplicated across a thousand codebases owned by many different teams. The mesh's sidecar proxies handle mutual TLS (mTLS) and per-request authorization uniformly, the control plane distributes identity and policy to every sidecar, and the API gateway stays a separate, thinner layer that only handles edge concerns (external traffic authentication, coarse rate limiting) rather than trying to be the single point enforcing every internal rule. Structured elaboration Identity model. Every service instance gets a workload identity, most commonly a SPIFFE (Secure Production Identity Framework For Everyone) identity encoded into a short-lived X.509 certificate, tied to what the workload is (its Kubernetes service account and namespace, for example) rather than a static shared secret. The mesh's control plane (Istio's istiod, for example) issues and continuously rotates these certificates automatically; no individual service team manages its own certificate lifecycle. Enforcing service-to-service auth and authorization. The sidecar proxy next to each service terminates and originates mTLS transparently, so two services communicate over an encrypted, mutually-authenticated channel without either one's application code implementing TLS itself. Authorization (which services may call which other services, and for which operations) is expressed as policy (Istio's AuthorizationPolicy resources, for example) and enforced by the sidecar before a request ever reaches the application, giving every service the same authorization enforcement mechanism regardless of what language or framework it is written in. Policy enforcement points. At this scale there are exactly two places policy actually gets enforced, and each has a distinct job: the API gateway is the enforcement point for traffic entering the mesh from outside (external clients, partners), handling coarse checks like authentication and rate limiting once at the edge; each service's own sidecar is the enforcement point for everything after that, deciding, per call, whether one internal service may reach another. Keeping these two enforcement points separate, rather than routing all internal traffic back through the gateway, is what keeps the gateway from becoming a bottleneck for traffic that never needed to leave the mesh. Minimizing blast radius. Default-deny between services (a service can only call, or be called by, the specific services its policy explicitly allows) turns a compromised service into a contained incident instead of a pivot point to the rest of the fleet; without this, one compromised service with network reachability to everything else effectively compromises the whole mesh. Centralizing policy without creating a bottleneck. Policy is authored and versioned centrally (so the security posture is auditable in one place, as code) but distributed to every sidecar so each one can make allow/deny decisions locally, at line rate, without a synchronous call back to a central decision service on every request. This is the key design move for enforcing at 1,000-service scale: centralize the authoring and distribution of policy, not the evaluation of it. Observability and incident response. Every sidecar can emit consistent access logs, metrics, and distributed traces for the traffic passing through it, giving uniform visibility across all 1,000 services without depending on each service team to instrument request-level auth logging themselves. This uniformity is what makes incident response at this scale tractable: a security team traces a suspicious request across service boundaries using the mesh's own telemetry rather than reconciling a thousand different logging formats. Rollout plan. Introduce the mesh incrementally rather than flipping mTLS enforcement on everywhere at once: start in permissive mode (the sidecar accepts both plaintext and mTLS traffic while metrics show which callers have and have not migrated), onboard services namespace by namespace or team by team, and only flip to strict mTLS enforcement for a given service once its traffic is confirmed fully migrated. A big-bang cutover at 1,000 services risks a simultaneous outage across the fleet if any meaningful fraction of callers have not yet adopted the sidecar. Scaling considerations. The sidecar's own resource footprint (CPU and memory per pod) and the control plane's config-push fan-out both need capacity planning at this scale; a control-plane change that pushes new policy to 1,000 sidecars simultaneously needs to be paced (canaried, rate-limited) rather than broadcast all at once, since a bad policy pushed everywhere simultaneously turns a policy bug into a fleet-wide outage instead of a contained one. Worked example mermaidgraph TD Ext[External Traffic] --> GW[API Gateway - Edge AuthN and AuthZ] GW --> SM[Service Mesh Ingress] SM --> SVA[Service A plus Envoy Sidecar] SM --> SVB[Service B plus Envoy Sidecar] SVA -->|mTLS plus SPIFFE ID| SVB CP[Istio Control Plane] -.->|distributes policy and certs| SVA CP -.-> SVB SVA --> OBS[Telemetry: access logs, traces] SVB --> OBS The gateway handles only the edge boundary (authenticating and rate-limiting external traffic before it enters the mesh at all); everything after that, service A calling service B, for example, goes sidecar-to-sidecar over mTLS with an authorization decision made locally by service B's own sidecar, based on policy the control plane already pushed to it. If the control plane is briefly unavailable, existing sidecars keep enforcing their last-known policy and certificates until they expire, since evaluation never depended on a live call to the control plane; only new certificate issuance and policy updates pause during that window, which is the direct payoff of "centralize distribution, not evaluation." Trade-offs and pitfalls A service mesh adds real operational complexity and per-request latency overhead (an extra network hop through the sidecar in each direction); this is a deliberate trade against the alternative of every service reimplementing TLS and authorization independently, which does not scale to 1,000 services being maintained correctly and consistently over time. The trade-off is worth stating explicitly rather than presenting the mesh as free. Permissive mode during rollout is a temporary state, not a target state. Leaving services in permissive mode indefinitely (common when a migration stalls) means mTLS is not actually being enforced for those services even though the infrastructure exists, which is easy to miss in metrics that only measure "sidecar deployed" rather than "strict mode enforced." Common wrong turn: routing all internal traffic back through the central API gateway to reuse its authorization logic. This defeats the scaling argument for a mesh in the first place and turns the gateway into both a latency bottleneck and a single point of failure for traffic that never needed to leave the mesh's own service-to-service path. Common wrong turn: pushing a policy change to all 1,000 sidecars simultaneously without a canary. A syntactically valid but logically wrong authorization policy (an overly broad deny rule, for example) pushed everywhere at once can cause a fleet-wide outage in the time it takes the control plane to distribute the update, which is why staged rollout applies to policy changes, not just to the initial mesh adoption.

HardTechnical

57 practiced

Provide a Redis Lua script (or clear pseudocode) that implements a distributed sliding-window rate limiter per key with parameters (limit, window_seconds). The script must atomically record the current request timestamp, remove expired entries, and return the current count and remaining allowance. Explain how TTL is used and how to call the script with EVALSHA for performance.

Sample Answer

Approach Use a Redis sorted set per rate-limit key, where each member is one request and its score is the request's timestamp in milliseconds. A single Lua script prunes expired entries, counts what remains, and conditionally records the new request, all atomically, since Redis runs an entire Lua script as one uninterruptible operation. This is illustrative Lua meant to be loaded with SCRIPT LOAD and called via EVALSHA; it was not executed against a live Redis instance in producing this answer, so no run transcript is claimed below, only the script and its documented return shape. lua-- KEYS[1] = rate limit key, e.g. "ratelimit:{user_id}" -- ARGV[1] = limit (max requests allowed in the window) -- ARGV[2] = window_seconds -- ARGV[3] = current timestamp in milliseconds -- ARGV[4] = unique request id (avoids collisions when two requests land in the same millisecond) local key = KEYS[1] local limit = tonumber(ARGV[1]) local window_ms = tonumber(ARGV[2]) * 1000 local now = tonumber(ARGV[3]) local member = ARGV[3] .. "-" .. ARGV[4] -- 1. Drop entries older than the window, atomically within this script redis.call("ZREMRANGEBYSCORE", key, 0, now - window_ms) -- 2. Count what remains in the window before adding this request local current = redis.call("ZCARD", key) if current < limit then -- 3. Record this request's timestamp redis.call("ZADD", key, now, member) -- 4. Bound memory: the key should not outlive the window redis.call("PEXPIRE", key, window_ms) return {1, current + 1, limit - current - 1} else -- refresh TTL even on rejection, so an idle-but-full key doesn't linger forever redis.call("PEXPIRE", key, window_ms) return {0, current, 0} end Return shape: {allowed (1 or 0), count_after, remaining}. Key points Atomicity: Redis executes an entire Lua script as a single atomic operation, no other command from any client can interleave between the prune, the count, and the write. Doing count-then-decide-then-write as three separate round trips would race under concurrency: two requests could both read a count of 9 against a limit of 10, both decide "allowed," and both write, letting 11 through. Why a sorted set: scoring each member by its millisecond timestamp turns ZREMRANGEBYSCORE key 0 (now - window) into an exact sliding-window prune in one command, and ZCARD after pruning gives the true count of requests strictly inside the current window, with no approximation. This is why it is called a sliding-window-log algorithm, in contrast to a fixed-bucket counter that resets on a clock boundary and can let roughly twice the limit through right at the boundary edge. Unique member per request: using the timestamp alone as the sorted-set member risks silently deduplicating two requests landing in the same millisecond under high queries-per-second (QPS) traffic, since sorted-set members must be unique. Appending a request ID avoids undercounting. TTL usage PEXPIRE key window_ms runs after every write, bounding the key's lifetime to roughly one window past the most recent request, so a client that stops calling entirely has its rate-limit key evicted automatically instead of sitting in memory forever. Refreshing it even on a rejected request keeps a currently-active, currently-abusive key alive for enforcement, while a truly idle key still expires on schedule. Calling with EVALSHA for performance EVAL sends the full script text over the wire on every call. SCRIPT LOAD uploads the script once and returns a SHA1 hash; every subsequent call then uses EVALSHA <sha> <numkeys> <key> <args...>, sending only the hash plus arguments, avoiding re-parsing and re-transmitting the script body on the hot path. Production clients typically call EVALSHA optimistically and fall back to a one-time EVAL (which also re-registers the script) if Redis responds with a NOSCRIPT error, for example after a Redis restart flushed the script cache, so the limiter survives a cache eviction without requiring a deploy. Complexity ZREMRANGEBYSCORE and ZADD are each O(log N + M), where N is the sorted set's size and M is the number of expired entries removed in this call. Since M is naturally bounded by the limit itself, you can never accumulate more entries than the limit allows, and each is removed exactly once, the amortized cost per call stays close to O(log limit), cheap even for a very hot key. Edge cases Clock skew across application servers, each independently supplying ARGV[3], can make the window fuzzy across servers; mitigate by having the script call Redis's own TIME command internally instead of trusting each caller's clock, trading a small amount of script complexity for correctness. A single extremely hot key, one abusive caller hammering the limiter, still funnels through Redis's single-threaded command execution, so a very high-QPS attacker against one key can itself become a load concern, worth pairing this with a coarser upstream limit. A retried or timed-out EVALSHA call must not double-count; treat the rate-limit check as best-effort-once per logical request, not blindly retried. Trade-offs & pitfalls Fixed-window counters are simpler and cheaper but let up to roughly twice the limit through at window boundaries, the exact boundary-burst problem this sliding-window-log design specifically avoids. A token-bucket algorithm is a common alternative that better supports controlled bursts, at the cost of a different mental model to reason about. This sorted-set approach uses O(limit) memory per key, one entry per request currently in the window, versus a fixed-window counter's O(1), a real cost at very high per-key limits.

EasyTechnical

99 practiced

What is an API gateway, and what security responsibilities does it typically take on for the services sitting behind it?

Sample Answer

That is every published API Security, Authentication and Authorization question for Cloud Engineer so far. Browse the other topics in this category, or practice this one interactively.

Browse APIs, Networking & Integration topics Start a practice session