HTTP basics, authentication, authorization and input safety

Why it matters

Almost every backend or full-stack exercise ends in an HTTP endpoint, and every endpoint makes two security decisions before it does anything useful: who is calling, and whether that caller may act on this particular object. Broken access control is the first category of the OWASP Top 10 (2025 edition), and many access-control bugs are not clever exploits but a handler that trusted an object ID from the request. AI-assisted products widen the surface: agents fetch URLs, call tools and process text written by strangers, so SSRF and injection stop being textbook topics. Interviewers use this area to see whether you design defensively by default rather than adding checks afterwards.

Core ideas

HTTP semantics. A request is a method, a target, headers and an optional body; a response carries a status code, headers and a body. RFC 9110 defines safe methods (GET, HEAD, OPTIONS, TRACE), which request no state change, and idempotent methods (the safe ones plus PUT and DELETE), where repeating a request has the same intended effect. POST and PATCH make no such promise, so retrying them safely needs an application-level idempotency key. Status codes communicate the class of outcome: 400 for malformed input, 401 when credentials are missing or invalid, 403 when the caller is known but not permitted, 404 when nothing is there. RFC 9110 also allows a server to answer 404 instead of 403 to avoid revealing that a forbidden resource exists.

Authentication versus authorization. Authentication establishes identity: a password with a second factor, single sign-on through OpenID Connect, an API key, a workload identity. Authorization decides whether that identity may perform this action on this object. OAuth 2.0 is a framework for delegated authorization; OpenID Connect adds an identity layer on top. Designs that treat "logged in" as "allowed" produce object-level access bugs, where any signed-in user can read another user's record by changing an ID.

Sessions and tokens. A server-side session keeps state on the server and gives the browser a random, opaque identifier in a cookie marked HttpOnly and Secure, with a SameSite policy; revoking it is a delete. A self-contained token such as a signed JWT lets services verify claims without a lookup, but you must check signature and algorithm, issuer, audience and expiry, and revocation becomes hard, so such tokens are kept short-lived and paired with refresh tokens. Cookies are sent automatically, which creates CSRF exposure; a token stored where JavaScript can read it is exposed to XSS.

Input safety. Injection happens when data crosses into an interpreter as code. Use parameterized queries, never string concatenation, and avoid passing user input to a shell. Cross-site scripting is injection into a page: rely on templating that escapes by context, treat raw HTML insertion as a review flag, and add a Content Security Policy as defense in depth. SSRF happens when your server fetches a URL the user influenced (webhooks, link previews, an agent's browsing tool) and reaches internal services or cloud metadata endpoints; allowlist destinations, check the resolved IP address rather than the hostname string, and re-check after redirects.

Tenant isolation. In a multi-tenant product the tenant comes from the authenticated principal, never from a request parameter, and every query, cache key, queue message, file path and search index carries it. Centralize the check in the data-access layer so a new endpoint cannot forget it, consider database row-level security as a second line, and write tests that try to read tenant B's object with tenant A's credentials.

Secrets. Keep keys out of source control and container images, inject them at runtime from a secret manager, scope them narrowly, rotate them, and scrub them from logs and error messages.

Common misconceptions

• "401 means not allowed." 401 means the request lacks valid authentication; an authenticated caller without permission gets 403, or 404 if existence should stay hidden.
• "JWTs are encrypted." Most are only signed, so anyone holding one can read its claims. Keep secrets out of them and validate every claim you rely on.
• "Input validation prevents injection." Validation narrows input, but the fix for injection is keeping data and code apart: parameterized queries and context-aware output encoding.
• "CORS protects my API." CORS controls which origins a browser lets read responses; it is not authorization and does nothing against non-browser clients.
• "Checking the tenant at the router is enough." Every data access path needs the check, including batch jobs, exports, admin tools and caches.
• "Environment variables make secrets safe." They keep secrets out of code, but secrets still leak through crash reports, debug endpoints and logs unless handled deliberately.

How to approach it

Read MDN's overview of HTTP, then the RFC 9110 sections on safe and idempotent methods and on 401 and 403. Work through the OWASP cheat sheets on authentication, sessions, authorization, multi-tenancy and SSRF as checklists rather than prose. In interviews, narrate both decisions for every endpoint you design: "the handler authenticates the session, loads the document scoped to the caller's tenant, then checks the role." At graduate level, interviewers mostly expect correct vocabulary and the obvious mitigations; at mid and senior level they probe failure paths such as token revocation, key rotation, how you would detect a cross-tenant leak, and how a security fix rolls out without breaking clients.