Security interview bank

Authentication validates a credential under server policy and produces a normalized principal: for example, a subject, tenant, authentication method, and trusted claims. Authorization takes that principal plus the requested action, target object, and context and decides whether to allow the operation. A valid token therefore is not permission to access every identifier accepted by an endpoint. I keep the stages separate, deny by default, and enforce authorization where the business read or write occurs. Tests cross users, tenants, methods, and object ownership, and they assert that denial leaves no side effect.

Every operation receiving an object identifier must prove that the current principal may perform that action on that object. I prefer to carry tenant and visibility constraints into the database query, then apply any richer state or relationship policy at the transactional write boundary. A missing or forbidden private object gets one consistent response, often 404, so existence is not disclosed. UUIDs may reduce casual enumeration, but clients still possess and exchange valid identifiers. Leaks, logs, references, or another endpoint can reveal one, so an unguessable ID never replaces authorization or cross-tenant tests.

First define the budget and its key: requests, bytes, concurrent jobs, or downstream cost per principal, tenant, credential, or trusted source network. All API instances must consume that budget through an atomic update in shared state, with a defined window, expiration, and retry response. Proxy addresses are accepted only from configured trusted hops. I also specify behavior when the limiter store fails; expensive or authentication operations often fail closed, while selected reads may degrade. Rate limiting reduces abuse, but it does not replace authorization, input bounds, idempotency, or workload-specific concurrency controls.

I start from the observable contract and trace every client-controlled identifier, method, property, and credential to its enforcement point. The endpoint must verify credentials under fixed server policy, deny action and object access by default, reject unknown input fields, and serialize only allowed output fields. Then I test the negative space: another user and tenant, alternate methods and versions, malformed and oversized bodies, concurrent writes, retries, and unavailable dependencies. Finally I inspect logs and errors for tokens or personal data and verify that every denied or failed path leaves storage and downstream systems unchanged.

I first distrust the appearance of completeness and trace every client-controlled value and claimed identity to its sink. The handler must derive its principal from verified server state, reject unknown or oversized input, authorize the action and object, bind interpreter parameters, and encode any output for its exact context. I distinguish CORS, CSRF, CSP, authentication, and authorization rather than accepting one as a substitute for another. Negative tests use another user and tenant, alternate methods and content types, malformed encodings, dependency failure, and concurrent requests. I also inspect post-proxy headers, logs, database state, emitted events, and downstream calls after every rejection.

CORS is a browser-enforced response-sharing policy. It lets a server say which page origins may read a cross-origin response through browser APIs such as Fetch. It is not server-side authentication or authorization because curl, backend services, and hostile clients do not have to enforce it. It is not CSRF protection either: a safelisted cross-origin request can reach the server and change state even when the browser hides its response. I therefore configure CORS narrowly, but still authenticate the caller, authorize every operation and resource, validate input, and protect cookie-backed state changes against CSRF.

A request outside the CORS safelists—such as PUT, JSON content, or an Authorization header—usually makes the browser send OPTIONS first. The preflight carries Origin, Access-Control-Request-Method, and the planned non-safelisted headers. The server answers with one matching allowed origin and the permitted methods and headers; credentialed use also needs the credentials response flag. If that policy passes, the browser sends the actual request. The actual response must still pass its own origin check. Preflight only approves the request shape, so the endpoint must independently authenticate, authorize, validate, and produce CORS headers on error paths.

I keep a reviewed set of complete origins, including scheme and port, and compare the serialized Origin by exact membership. On a match, the response returns that one origin plus Access-Control-Allow-Credentials set to true; it never combines several origins or uses a wildcard. Because the selected header varies with the request, I merge Origin into Vary so shared caches separate variants. The client must choose the appropriate credentials mode, and cookie SameSite, Secure, domain, and browser policy still apply. None of those settings grants user permission, so the actual endpoint keeps independent authentication, authorization, and CSRF defenses.

I reproduce it from a page running at the exact production origin and inspect both OPTIONS and the actual request in browser developer tools. I compare Origin, requested method and headers, credentials mode, status, redirects, and every Access-Control response header. Then I inspect the final response after CDN, gateway, and application processing because duplicate headers, missing Vary, or infrastructure-generated errors may differ from local middleware output. I test an allowed and denied origin and bypass caches only as a diagnostic control. Curl can confirm raw HTTP, but a real browser must verify response exposure and cookie-policy behavior.

CSP is a browser-enforced second boundary, not an input sanitizer. The application still encodes output for its HTML, attribute, URL, or script context and avoids unsafe DOM sinks. CSP then limits which scripts and resources may execute if injection survives. I start from default-src and explicit directives, avoid broad wildcards and unsafe-inline, and use a fresh response nonce only where inline script is necessary. I also constrain frame ancestors, form targets, and base URLs explicitly because they do not all inherit from default-src, then prove the policy with a blocked browser test.

I first inventory every subdomain, certificate path, third-party host, and recovery endpoint, because includeSubDomains extends the commitment beyond the main site. HSTS is sent only over valid HTTPS. I begin with a short max-age, watch certificate renewal and redirects, then extend the lifetime in reviewed stages. I add includeSubDomains only after the namespace is ready and submit for preload only when the organization accepts a slower removal process. The rollback plan sends max-age=0 over working HTTPS, but I explain that disconnected users cannot receive it and preload removal depends on browser updates.

A nonce must be unpredictable, generated with a cryptographic source for one response, and copied exactly into that response’s CSP and approved script or style elements. It is authorization for those elements, not escaping for data placed inside them. I reject process-global, build-time, sequential, or user-derived values. The HTML and policy header must remain one cache object; a CDN cannot regenerate one side or reuse personalized HTML across requests. Tests compare the two locations, confirm consecutive responses differ, inject a script without the nonce, and verify in a real browser that only the approved element runs.

I inspect the final response after the CDN, gateway, cache, framework, and route have all acted. Raw HTTP tests cover representative content types and statuses, including redirects, authentication failures, 404, oversized requests, rate limits, and upstream errors. They catch missing, duplicate, or overwritten fields. Then browser tests prove enforcement: a nonce-free script is blocked, an attacker origin cannot frame the page, a mismatched script MIME type fails, and disabled features remain unavailable. I keep application-origin responses as a diagnostic comparison, but they do not prove what users receive or how a browser applies it.

I test the path from input to the peer selected for the socket. Cases include near-miss hostnames, credentials in authority, explicit ports, IPv4 and IPv6 special ranges, mapped addresses, mixed and changing DNS answers, relative and absolute redirects, and resolver failure. Instrumentation proves which address was connected and which hostname TLS verified. Then I exercise oversized and compressed bodies, slow streams, redirect loops, retries, and concurrency limits. From the deployed workload I also try direct routes around the approved client or proxy and confirm that egress policy blocks internal services and metadata independently of application code.

SSRF occurs when untrusted input influences a network request made with a server’s reach, identity, or credentials. The server can then reach loopback, private services, metadata endpoints, or public operations the caller could not invoke directly. My first defense is to remove arbitrary destination choice: the caller supplies a server-defined service ID and bounded data such as an encoded path segment, while configuration owns the scheme, exact host, port, method, credentials, and response contract. If arbitrary public URLs are essential, they go through one default-deny outbound policy plus independent egress controls.

Validation and connection are separate unless they share the same resolution result. Code may approve a public address, then pass the original hostname to a client that performs another lookup and receives a private or link-local answer. I validate every selectable A and AAAA result, including mapped forms, and bind one approved address to the socket through a supported lookup hook or policy proxy. For HTTPS I keep the original hostname for certificate verification, SNI, and HTTP authority. New sockets, retries that resolve again, and every redirect require another policy decision; DNS caching alone is not that binding.

A redirect is a new destination, not a continuation of the first approval. I disable automatic following, resolve a relative Location against the current URL, and repeat scheme, exact host, effective port, DNS-address, and connection-binding checks before the next hop. I cap redirect count and define method and body behavior for each accepted status. Headers are rebuilt from a small server-side allowlist at every hop. Inbound Authorization, Cookie, proxy, and forwarding headers never flow through, and service credentials are attached only after policy identifies their configured audience, even when two hosts are both approved.

I trace concrete data and identity flows instead of starting with a vulnerability checklist. I mark attacker-controlled sources, parsers and normalizers, privileged operations, output contexts, and every browser, proxy, application, database, or downstream-service boundary. For each sensitive action I name the trusted principal, target object, allow condition, rejection response, and side effects. Then I choose controls at their actual enforcement points: validation for the business contract, authorization at the object operation, parameter binding at the interpreter, and contextual encoding at output. I finish with counterexamples that swap users, tenants, methods, origins, and malformed values.

Validation answers whether a value belongs to the business domain, such as an integer in range or one known status. It does not define how a later interpreter treats that value. SQL parameters preserve the boundary between query syntax and values even when a valid business string contains a quote. Contextual output encoding preserves the boundary between text and HTML, URL, CSS, or JavaScript syntax. I validate early for a narrow contract, keep the canonical value, and still apply the sink-specific control where the value is used. Blacklists fail because encodings, parser differences, and new contexts create forms they did not anticipate.

I require an explicit non-safe HTTP method, authenticate the server-side session, and authorize the action and target object at the mutation boundary. Because the browser attaches the cookie automatically, I also verify an unpredictable CSRF token bound to that session and compare the request Origin against exact normalized origins. Secure, HttpOnly, and an appropriate SameSite setting reduce exposure but do not replace those checks. The mutation validates its business payload, runs transactionally or idempotently as required, and rejects before any irreversible work. Tests cover missing and wrong tokens, hostile origins, another valid user, retries, and the final cookie behavior in a browser.