Web protocols & security
HTTP semantics, the TLS handshake beneath it, the certificate chains that prove a server's identity, and the browser rules gating cross-origin calls. Interviewers probe it for stack-level reasoning.
on this pageshowhide
guide
overview
~2 minWeb protocols and security is the ground between a URL and the bytes a script finally reads: the HTTP exchange, the TLS channel it travels in, the certificates that let a client believe it reached the right server, and the rules a browser applies before one site's page may act on another site's data. Interviewers use it to test stack-level reasoning. When a call fails, can you say which layer refused it, which party made that decision, and where the evidence lives? A status code, a handshake alert, a rejected certificate path and a blocked cross-origin read can look alike from inside the application and mean different things. The subject splits into five sections. [HTTP](/topics/proto-http) is the largest: methods and the guarantees they carry, status codes, headers, caching and validators, connection reuse, the binary framing of HTTP/2 and HTTP/3, cookies and the authentication framework. [TLS](/topics/proto-tls) is the wire protocol underneath: the handshake, key exchange, cipher suites, resumption, the differences between versions, mutual authentication, termination at proxies and the diagnosis of failed handshakes. [PKI](/topics/proto-pki) explains how a public key becomes a trusted name: X.509 fields, chain building, trust stores, revocation, issuance and its automation, and Certificate Transparency. [HTTPS](/topics/proto-https) is the policy a browser layers on a site once it is served over TLS: HSTS, mixed content and hardening response headers. [Browser trust boundaries](/topics/proto-browser-security) covers CORS, CSP and CSRF, where the server states a policy and the browser carries it out. Learn HTTP semantics first, because most later sections are expressed through requests, responses and headers. Take TLS and PKI next and together: a handshake makes no sense without the certificate it carries, and a certificate means nothing until you know how a client checks it. Leave HTTPS policy and the browser boundaries for last, since they assume you already know what an origin, a cookie and a secure connection are. Questions run from what a status code or cookie attribute does up to why a revocation design accepts risk on purpose, so revisit a section as your level rises.
primer
A few ideas hold the subject together; with them in place, most questions below read as consequences rather than trivia. - **Each layer answers a different question.** HTTP says what was asked for and what happened. TLS says the bytes were private and unaltered and that the peer holds a particular key. PKI says whose key that is. Browser policy says which page is allowed to act on the result. Confused answers usually borrow a guarantee from the wrong layer, such as expecting encryption from an encoding or identity from a cipher. - **Protocol semantics are promises strangers rely on.** Method properties, status classes and cache directives are read by proxies, caches, retry logic, crawlers and client libraries that know nothing about your application. Using `GET` for a state change or the wrong 4xx code is not a style issue; it misleads components you do not own. - **Identity is imported, never self-asserted.** A certificate proves nothing on its own. Trust flows from an anchor the client already holds, down a path of signatures and matching names, and is tied to the live connection only when the server proves it holds the private key. The certificate is public; the key is the secret. - **Every guarantee has an edge.** A browser policy learned from a response cannot cover the request before it. Revocation only counts if the client fetches it. A resumed session skips work the first handshake did. A cookie restriction covers some request types and not others. Many senior questions are about where a guarantee stops. - **The server declares; the browser enforces.** CORS, CSP, HSTS, mixed-content blocking and cookie attributes are instructions a conforming browser follows. Other clients generally ignore them, which is why none of them replaces authorization on the server, and why CORS protects the user's data in the browser rather than the server itself. - **Some failures are opaque by design.** A blocked cross-origin call hands script almost nothing; a TLS alert is a short code; a missing intermediate breaks only some clients. Knowing where the real evidence sits (the network panel, the alert number, the chain the server actually sent) is part of the answer. - **Speed comes from not repeating work.** Connection reuse, multiplexing, resumption and caching each avoid a round trip, and each brings a correctness or security question with it.
- Origin
- The scheme, host and port of a URL taken together; the unit browsers use to decide which pages may read each other's data and which cookies and storage they share.
- Same-origin policy
- The browser's default rule that a page's script may send requests elsewhere but may not read responses from a different origin unless that origin grants it.
- Safe method
- An HTTP method whose request asks the server for no state change, so crawlers, prefetchers and caches may issue or repeat it freely.
- Idempotent method
- An HTTP method where repeating the identical request has the same intended effect on the server as sending it once, which is what makes automatic retry defensible.
- Validator
- A value such as an entity tag or a last-modified date that lets a cache ask the origin whether its stored copy is still current without downloading it again.
- Head-of-line blocking
- A stall where one lost or slow unit holds up everything queued behind it; a problem HTTP/2 and HTTP/3 each attacked at a different layer.
- Forward secrecy
- The property that recorded traffic stays unreadable even if a server's long-term private key is later stolen, because session keys came from ephemeral key exchange.
- Cipher suite
- The named combination of algorithms a TLS connection uses; its contents differ between versions, since newer versions negotiate key exchange and authentication separately.
- Trust anchor
- A certificate or key the client already accepts without proof, held in a local trust store; every certificate path must end at one.
- Intermediate certificate
- A CA certificate between the root and the server's own certificate; the server is expected to send it, and forgetting to is a classic partial outage.
- Subject Alternative Name
- The X.509 extension listing the DNS names and IP addresses a certificate is valid for; the field clients check the requested host name against.
- Revocation
- An issuer's separate, signed statement that a certificate should no longer be trusted before its expiry; clients learn of it only by obtaining that statement.
- Certificate Transparency
- A system of public append-only logs recording issued certificates, so domain owners and monitors can detect issuance they never asked for.
- Preflight request
- An OPTIONS request a browser sends before certain cross-origin calls to ask the target whether the real request's method and headers are permitted.
- Ambient credentials
- Credentials such as cookies that a browser attaches automatically based on the destination, whichever page triggered the request; the root cause of CSRF.
- Content Security Policy
- A policy, usually sent as a response header, that tells the browser which sources a page may load scripts, styles and other resources from, limiting what injected markup can do.
The sections are easiest to connect by following one request from a browser tab to a server and back. ### Before anything is sent The browser applies policy first. A host it has stored as HSTS gets its `http` URL rewritten to `https` locally, and a secure page asking for an insecure subresource meets the mixed-content check. Both belong to [HTTPS](/topics/proto-https), and both run before a single packet leaves the machine. A cross-origin call that is not simple triggers a preflight, which is the first place [CORS](/topics/proto-cors) shows up on the wire. ### Opening the channel The client opens a connection, or reuses one, and runs the [TLS handshake](/topics/proto-tls-handshake). Inside it the server sends a certificate chain, and this is where [PKI](/topics/proto-pki) takes over: the client builds a path to an anchor in its trust store, checks names, validity and possibly revocation, and then checks the server's proof that it holds the matching key. Key exchange, cipher suites, resumption and versions decide how costly and how strong that step is. A load balancer that terminates TLS splits this picture in two, with one handshake at the edge and a separate, possibly plaintext, hop behind it. ### The exchange and what the browser does with it Over the protected channel, [HTTP](/topics/proto-http) carries the request: method, headers, cookies and credentials under the authentication framework. HTTP/2 and HTTP/3 change how those messages are framed and multiplexed, not what they mean. The response comes back with a status, cache directives and a set of policy headers, and the browser acts on them: it stores or refuses to store, grants or withholds a cross-origin read, restricts where [CSP](/topics/proto-csp) lets scripts load from, and records cookie attributes that later decide whether a forged cross-site request arrives authenticated, which is the concern of [CSRF](/topics/proto-csrf). Read this way, the hub is one pipeline. A good interview answer names the stage where something went wrong before it names the fix.
- Methods and Status Codes →
The vocabulary of every exchange: what methods promise and what status classes tell clients, proxies and retry logic. Most later sections assume it.
- Caching and Conditional Requests →
Caching is where header semantics turn into real behaviour and real outages, and it teaches the reading of directives that the policy headers reuse.
- Handshake and Extensions →
The single exchange that ties keys, versions and server identity together; certificates, resumption and troubleshooting all refer back to its message order.
- Trust Chains & CAs →
How a client decides to believe a certificate. Without path building and anchors, handshake failures and chain gaps stay mysterious.
- CORS →
The browser boundary most backend engineers meet first, and the clearest example of a server declaring policy that only the browser enforces.
- HSTS and Preload →
A short section that shows how a browser policy is learned, where its protection begins, and why a long-lived policy is hard to undo.
Treating Base64 in a Basic
Authorizationheader as protection; it is an encoding, and only the TLS channel keeps the credential secret.Answering "we use HTTPS" to a security question, when HSTS, mixed-content rules, cookie attributes and response headers decide what the browser actually enforces.
Believing CORS protects the server from other callers; it governs what a browser lets a page read, and any non-browser client can call the endpoint directly.
Reflecting the incoming
Origininto the allow-origin response header and calling it an allow-list; see origin reflection.Saying the certificate proves identity by itself, forgetting the signature over the handshake that shows the server holds the private key.
Testing a chain from one well-configured machine and declaring it fine, when a missing intermediate only fails for clients that cannot fill the gap themselves.
Claiming revoked certificates stop working immediately, without asking whether clients fetch status at all and what they do when the check cannot complete.
Changing state on
GET, which breaks caching and prefetch assumptions and leaves the action forgeable even under aLaxcookie policy.Setting a long HSTS
max-agewithincludeSubDomainsbefore every subdomain serves valid TLS, then discovering there is no quick way back.
A handful of choices recurs across the sections; naming the one you are making earns more credit than reciting a header. - **Cacheability versus freshness.** Every cache directive trades origin load and latency against the risk of serving something outdated or private. The right setting depends on who may see the response and how wrong a stale copy is allowed to be, not on a default copied from another service. - **Latency versus security margin.** Fewer round trips come from resumption, early data and long-lived connections, and each one gives something up: replay exposure, weaker binding to a fresh authentication, or state that outlives the reason it was created. - **Fail closed versus fail open.** Revocation checking and HSTS protect users only if a failed check stops the connection, and stopping the connection costs availability when the checking infrastructure is down. Say which side a design chose and why. - **Termination point versus end-to-end protection.** Ending TLS at the edge simplifies certificates, inspection and routing, and it leaves a hop where traffic may be readable. Whether that hop is re-encrypted, and who can see it, is part of the answer. - **Strict policy versus deployability.** A tight CSP, a narrow CORS grant or a strict cookie mode blocks attacks and breaks legitimate integrations. Report-only modes and gradual rollouts exist because turning a policy on is easy and discovering what it broke is not. - **Certificate lifetime versus operational load.** Short lifetimes shrink the damage window of a compromised key and push toward full automation; long lifetimes are easier to operate and lean harder on revocation working.
Several shapes recur under different names; recognising them places an unfamiliar question quickly. - **Declare, then enforce elsewhere.** A server sends a header and a different party applies it: the browser for CORS, CSP, HSTS and cookie attributes, a cache for cache directives. The question to ask is always who enforces this, and who ignores it. - **The first contact is the weak one.** Policies learned from a response cannot protect the request that fetched them, and trust set up on first use depends on that first use being clean. Preload lists and pre-distributed data exist to close this gap. - **Prove possession, not just knowledge of a name.** A certificate names a key, a challenge in automated issuance proves control of a domain, a session token proves only that someone holds it. Many questions reduce to what exactly has been proven and to whom. - **Negotiation with a safe fallback.** Versions, cipher suites, content types, compression and application protocols are all agreed by offer and choice. Interviewers probe what happens when the peers share nothing, and whether an attacker can push them toward the weakest option. - **Opaque failure, specific evidence.** Browsers and handshakes hide detail from the application on purpose. The debugging pattern is the same each time: find the layer that has the real diagnostic (the network panel, the alert code, the actual chain served) and read that instead of the error message.
explore
- HTTP (has its own guide)166 questions
- Methods and Status Codes33 questions
- Headers and Metadata18 questions
- Caching and Conditional Requests23 questions
- Connections and Keep-Alive21 questions
- Binary Framing Versions22 questions
- Content Negotiation16 questions
- Cookies15 questions
- Authentication Framework18 questions
- HTTPS15 questions
- HSTS and Preload6 questions
- Mixed Content4 questions
- Response Security Headers5 questions
- TLS58 questions
- Handshake and Extensions6 questions
- Record Layer5 questions
- Key Exchange and PFS4 questions
- Cipher Suites4 questions
- Certificate Messages6 questions
- Session Resumption5 questions
- Version Differences4 questions
- Legacy SSL Breaks5 questions
- Mutual Authentication5 questions
- Termination and Interception3 questions
- Diagnosing Handshake Failures5 questions
- Datagram Mode6 questions
- PKI40 questions
- X.509 Certificates5 questions
- Trust Chains & CAs5 questions
- CSR & Certificate Issuance5 questions
- ACME Automation5 questions
- Revocation (CRL & OCSP)5 questions
- Certificate Transparency5 questions
- Key Management & Lifecycle5 questions
- Trust Stores5 questions
- Browser Trust Boundaries77 questions
→ has its own guide
- AI Red Teamingroleanchors this topic
- API Designskillanchors this topic
- Backend Developerroleanchors this topic
- Cyber Security Expertroleanchors this topic
- DevOps / SRE Engineerroleanchors this topic
- DevSecOps Engineerroleanchors this topic
- Frontend Developerroleanchors this topic
- Full Stack Developerroleanchors this topic
- Java Backend Developerroleanchors this topic
- Kotlin Backend Developerroleanchors this topic
- Network Engineerroleanchors this topic
- Software Architectroleanchors this topic
- AI Engineerrole
- API Testingskill
- Computer Scienceskill
- Data Engineerrole
- GraphQLskill
- Java SDETrole
- MLOps Engineerrole
- QA Engineerrole
- iOS Developerrole
questions
356 · 5 sectionsWalk me through exactly what a client puts in the HTTP Authorization header when using Basic authentication, and what protection that encoding gives you.
basics
~20 sThe client sends Authorization: Basic <base64 of userid:password>, recomputed on every request. Base64 is reversible encoding, not encryption or hashing — anyone who captures the header decodes the password instantly, so only TLS provides confidentiality.
How is a bearer token transmitted on an HTTP request per RFC 6750, and what does the word 'bearer' actually mean about how the server treats it?
basics
~20 sSend Authorization: Bearer <token> on each request, over TLS. 'Bearer' means possession alone proves authorization: the request carries no proof of who is holding it, so whoever copies the token can use it exactly like the legitimate client.
Walk through the HTTP challenge-response authentication flow: what does a 401 Unauthorized response carrying a WWW-Authenticate header tell the client, and what exactly does the client send back?
basics
~20 sThe server refuses with 401 and a WWW-Authenticate header naming an authentication scheme, usually plus a realm. The client gets credentials for that scheme and retries the same request with an Authorization header. HTTP is stateless, so the header repeats on every later request.
Explain the difference between the HTTP response headers `Cache-Control: no-cache`, `Cache-Control: no-store` and `Cache-Control: must-revalidate`, and give a case where each is the right choice.
basics
~20 sno-store means never write this to any cache. no-cache means you may store it but must check with the origin before every reuse. must-revalidate means you may serve it freely while fresh, but once it expires you must revalidate rather than serve it stale. Use no-store for secrets, no-cache for always-current data, must-revalidate when stale answers are unacceptable.
In HTTP caching, what does it mean for a stored response to be fresh versus stale, and what is a cache allowed to do once a stored response goes stale?
basics
~20 sA stored response is fresh while its age is below its freshness lifetime; it can be reused with no network trip. Once age exceeds that lifetime it is stale — which does not mean deleted. The cache normally revalidates with the origin, and a successful check makes the copy usable again with a reset clock.
What does a Strict-Transport-Security response header tell a browser to do, and why can it not protect the very first request?
basics
~20 sStrict-Transport-Security tells a browser to rewrite every later request for that host to https before the request leaves the machine, for max-age seconds. The browser learns the policy only from a response, so the first plaintext request stays unprotected.
An archive viewer served over HTTPS loads a plaintext script and a plaintext scanned image - why is only one blocked?
basics
~20 sThe script is blockable mixed content, so the browser fails that request as a network error. The image falls in the narrow upgradeable category, so the browser rewrites its URL to https and fetches it instead of blocking it.
What does `X-Content-Type-Options: nosniff` tell a browser to do with a response's declared Content-Type?
basics
~20 sIt sets the no-sniff flag, so the browser takes the declared Content-Type as the computed type instead of guessing one from the response bytes. nosniff is the only defined value, matched without regard to ASCII case.
What does the `Referrer-Policy` response header control, and which URL parts does a browser always remove?
basics
~20 sReferrer-Policy is a response header that tells a conforming browser how much of the current page's URL to put in the Referer request header on outgoing requests. Username, password and fragment are removed in every case.
In a Strict-Transport-Security header, what is the max-age directive counting, and what does max-age=0 signal?
basics
~20 sThe Strict-Transport-Security max-age directive is a required delta-seconds value counting from the moment the browser received the header; it is how long that host stays a Known HSTS Host. max-age=0 tells the browser to drop the stored entry.
In a TLS 1.3 handshake, which two messages does the server use to send its certificate chain and prove it holds the matching private key?
basics
~20 sCertificate carries the chain as a certificate_list of CertificateEntry structures. CertificateVerify carries a signature over the handshake transcript, made with the private key of the first certificate in that list. The chain alone proves nothing.
In a TLS 1.2 cipher suite name such as TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, what does each element select?
basics
~20 sA TLS 1.2 suite name lists four choices in fixed order: the key exchange, the algorithm that authenticates the server, the bulk cipher with its key size and mode, and the hash used for the record MAC or the pseudorandom function.
What breaks if unmodified TLS records are sent over UDP, and what does DTLS change to fix it?
basics
~20 sTLS assumes an ordered, reliable byte stream: drop or reorder one record and decryption fails, and a lost handshake message stalls forever. DTLS puts that back into the protocol itself with explicit per-record numbering, fragmented handshake messages and its own retransmission timer.
In a TLS 1.3 handshake, what has both sides agreed by the time the client sends its first application byte?
basics
~20 sA completed TLS 1.3 handshake has fixed one protocol version and one cipher suite, derived shared traffic keys, established the server's identity by signature, selected an application protocol, and confirmed both peers saw an identical message transcript.
In ACME, which steps run between creating a new order for a DNS name and downloading the issued certificate chain?
basics
~20 sAn ACME order for a DNS name becomes one authorization per identifier; the client completes one challenge in each, the server validates it, then the client posts a certification request to the order's finalize URL and downloads the chain.
In Certificate Transparency, how would your team learn that a publicly trusted certificate exists for a portal name nobody requested?
basics
~20 sPublicly trusted certificates are recorded in public append-only Certificate Transparency logs before clients will accept them, so a monitor watching your portal's DNS names reports any certificate issued for them, including one your team never asked for.
What does a PKCS#10 certification request send to a certificate authority, and what stays behind with the applicant?
basics
~10 sA PKCS#10 certification request carries the subject name being asked for, the public key and any requested extensions, all self-signed with the matching private key. The private key is not sent to the authority.
A server's private key file and its certificate are both committed to a public repository - which disclosure matters, and why?
basics
~20 sOnly the private key matters. An end-entity certificate is handed to every client that connects, so publishing it costs essentially nothing; the private key is the one secret that proves a server is entitled to use that certificate.
An end-entity certificate on a lift gate was revoked yesterday - what actually changed, and how would a client find out?
basics
~20 sNothing in the certificate changed: the same bytes, the same issuer signature, the same notBefore and notAfter. The issuer publishes the withdrawal separately, as a signed revocation list or a signed responder answer, and a verifier learns of it only by fetching one.
Why does a cross-origin request the browser blocks reach the calling script with no status code and no body?
basics
~20 sA failed CORS check replaces the server's response with a network error before script sees it - type "error", status 0, an empty header list, a null body - so the call rejects with a bare TypeError that carries no protocol detail at all.
A cross-origin lookup shows an OPTIONS request on the wire before the real one - what does the browser put in it?
basics
~10 sA CORS-preflight request: method OPTIONS, the calling page's Origin, Access-Control-Request-Method naming the method the real call will use, Access-Control-Request-Headers listing any CORS-unsafe request-header names, and Accept: /. It carries no body.
A cross-origin response carries a custom X-Gauge-Reported-At header that script cannot read - which response field makes it readable?
basics
~10 sAccess-Control-Expose-Headers, sent by the server on that response, names the extra fields script may read. Without it a cross-origin caller sees only seven names: Cache-Control, Content-Language, Content-Length, Content-Type, Expires, Last-Modified and Pragma.
What exact value does a browser put in the `Origin` request header for a page at `https://board.example.org/embed/arrivals?stop=42`?
basics
~10 sThe Origin request header carries only scheme, host and a non-default port: https://board.example.org. The path, the query, the fragment and any trailing slash are absent, and scheme and host are ASCII-lower-cased.
In a Content-Security-Policy, what does default-src do for the fetch directives you did not write?
basics
~20 sdefault-src supplies the source list for any fetch directive absent from the policy. A directive you do write takes nothing from it - the written list replaces the default wholly for that resource type, and an empty list blocks everything.