HTTP

Cybersecurity / 24 Sep 2026 / 5 min read

security.txt Publishes a Bounded Vulnerability Reporting Route

A security flaw can be difficult to report even when the affected service is easy to identify. A generic support form may route the message to the wrong queue, an old security mailbox may no longer be staffed, and a researcher cannot safely infer disclosure policy from a company name alone. RFC 9116 addresses that routing problem with security.txt, a small machine-parsable file published by the service operator. The file does not certify that a service is secure, authorize testing, or define a complete vulnerability disclosure program. Its narrower job is to publish current reporting coordinates and related metadata at a predictable location.

Cybersecurity Vulnerability Disclosure

Cybersecurity / 24 Sep 2026 / 5 min read

HTTP Message Signatures Bind Selected HTTP Components

TLS protects an HTTP exchange while traffic moves across a TLS connection, but some application designs need a cryptographic assertion attached to the HTTP message itself. A gateway may terminate TLS before forwarding a request, a service may need to authenticate selected request metadata, or a message may cross several HTTP hops where transport protection and application trust are separate concerns. HTTP Message Signatures, specified in RFC 9421, address that boundary. A signer chooses HTTP message components, constructs a defined signature base, signs it, and sends metadata that tells a verifier which components and parameters were covered. The mechanism is selective by design: a signature does not automatically cover every field or every property of the message.

Cybersecurity HTTP

Cybersecurity / 24 Sep 2026 / 5 min read

HSTS Keeps HTTPS Downgrades Out of Later Connections

TLS protects an HTTPS connection only after the client has chosen HTTPS and completed the TLS handshake. That leaves a separate problem at the scheme boundary. A user can enter a bare hostname, follow an old http:// link, or reach a redirect that starts in cleartext. An attacker able to interfere with that first HTTP exchange can try to keep the browser away from HTTPS. HTTP Strict Transport Security (HSTS), defined by RFC 6797, moves that decision into the user agent. After a host sends a valid Strict-Transport-Security header over a secure connection, a conforming user agent records the policy. During its lifetime, later attempts to contact that host with HTTP are converted to HTTPS before an HTTP request is sent.

Cybersecurity HTTPS

Cybersecurity / 23 Sep 2026 / 6 min read

HTTP Strict Transport Security Pins HTTPS for Future Visits

HTTP Strict Transport Security Pins HTTPS for Future Visits TLS protects an HTTP connection only after the client is using HTTPS. A user who enters a bare hostname, follows an old http:// link, or reaches a redirecting HTTP endpoint can still begin with an unencrypted request. HTTP Strict Transport Security (HSTS) gives a supporting browser a persistent rule for that host. After receiving a valid Strict-Transport-Security header over HTTPS, the browser records the policy and rewrites later HTTP navigation to HTTPS while the policy remains active.

Cybersecurity HTTPS

Software Engineering / 22 Sep 2026 / 8 min read

Optimistic Concurrency Rejects Stale Writes Before They Replace Newer State

Optimistic Concurrency Rejects Stale Writes Before They Replace Newer State A read-modify-write flow looks harmless when only one actor touches a record. A client reads state, changes part of it, then writes the result back. With concurrent actors, the interval between the read and the write becomes a race. Another writer can commit a newer value during that interval, and an unconditional update can erase it. Optimistic concurrency control puts a condition on the final write. The client carries a version derived from the state it read, and the storage layer accepts the mutation only if that version is still current. A mismatch becomes a conflict rather than a silent overwrite.

Software Engineering Concurrency

Cybersecurity / 21 Sep 2026 / 5 min read

The __Host- Cookie Prefix Narrows Session Cookie Scope

The __Host- Cookie Prefix Narrows Session Cookie Scope A session cookie can carry a strong random identifier and still have an unnecessarily broad scope. The Domain attribute can make a cookie available across subdomains, while a path-specific cookie can coexist with another cookie of the same name. Those details matter when several applications share a registrable domain but do not share the same security boundary. The __Host- cookie-name prefix gives supporting user agents a compact rule set for a stricter cookie. A cookie whose name begins with __Host- must be set from a secure origin with Secure, must use Path=/, and must omit Domain. A user agent that implements the prefix rejects a prefixed cookie that violates those constraints.

Cybersecurity HTTP

Cybersecurity / 21 Sep 2026 / 5 min read

SameSite Cookies Constrain Cross-Site Session Sending

SameSite Cookies Constrain Cross-Site Session Sending A session cookie is an ambient credential: once stored, the browser can attach it to matching HTTP requests without application code copying the value into each request. That convenience also creates a security boundary. A request initiated from another site can reach an application while carrying the user’s authenticated session unless cookie policy prevents it. The SameSite attribute gives the browser a rule for deciding whether a cookie may accompany a request in a cross-site context. It does not change the cookie value or authenticate the request by itself. It changes when the browser includes that cookie.

Cybersecurity HTTP

Cybersecurity / 21 Sep 2026 / 4 min read

Permissions Policy Limits Powerful Browser Features

Permissions Policy Limits Powerful Browser Features A web page can contain code from several trust domains while still sharing access to browser capabilities. First-party scripts, third-party widgets, and nested frames may all execute inside one application surface. Browser permission prompts remain important, but an application can narrow the set of documents that are eligible to request or use selected features before a prompt becomes relevant. Permissions Policy provides that boundary. A response header declares which origins may use controlled features in the document and its frame tree. The policy does not grant a user permission. It constrains feature availability within the browser.

Cybersecurity Web Security

Cybersecurity / 21 Sep 2026 / 5 min read

Fetch Metadata Headers Filter Cross-Site Requests

Fetch Metadata Headers Filter Cross-Site Requests A web server often receives requests that look valid at the HTTP layer even when they originated from an unrelated site. Cookies may accompany those requests, and a state-changing endpoint can be exposed if its defenses treat every browser request as equally trustworthy. Fetch Metadata gives the server additional context. Supporting browsers attach Sec-Fetch-* request headers that describe the relationship between the initiator and target, the request mode, the destination, and whether navigation resulted from direct user activation. A server can use that context as an early resource-isolation gate.

Cybersecurity Web Security

Cybersecurity / 20 Sep 2026 / 7 min read

Trust Forwarded Headers Only from Known Proxies

Trust Forwarded Headers Only from Known Proxies A reverse proxy often knows facts that an application server cannot observe directly. It may terminate TLS, accept the public hostname, and receive the client connection before opening a separate connection to the backend. Forwarding fields carry those facts across the second hop. That arrangement is safe only when the backend can distinguish proxy-supplied metadata from client-supplied HTTP fields. A header name does not create trust. The trust comes from the network path, the proxy configuration, and a rule that defines which hop may set or replace each field.

Cybersecurity Reverse Proxy

Cybersecurity / 20 Sep 2026 / 7 min read

TLS Early Data Needs Replay-Safe Application Semantics

TLS Early Data Needs Replay-Safe Application Semantics TLS 1.3 can carry application data in the client’s first flight when the client and server share a suitable pre-shared key (PSK), commonly from an earlier connection. This mode is called early data or 0-RTT. It removes a handshake wait from the critical path for eligible application traffic, but the latency reduction comes with a narrower security contract. The central constraint is replay. TLS does not provide a non-replay guarantee for 0-RTT data across connections. A server can deploy anti-replay mechanisms, yet the application still has to treat early data as potentially replayed. That distinction matters whenever one accepted request can change durable state, consume a one-time capability, trigger an external action, or produce another effect that should occur only once.

Cybersecurity TLS 1.3

Software Engineering / 19 Sep 2026 / 7 min read

Idempotency Keys Bind Retries to One Logical Mutation

A client can lose an HTTP response after the server has committed the requested mutation. From the client’s perspective, the operation is unresolved: the connection failed, but that failure does not reveal whether durable state changed. Retrying the same POST can then create a second order, payment attempt, reservation, or other mutation. An idempotency key gives the retry a stable identity that is separate from any single transport attempt. The server can associate repeated requests carrying that identity with one logical operation. That mechanism narrows an ambiguity at the API boundary, but the key alone is not a guarantee. Its scope, persistence, request comparison, concurrency control, and replay policy determine what repeated delivery actually means.

Software Engineering HTTP

Cybersecurity / 19 Sep 2026 / 6 min read

HTTP/1.1 Framing Disagreement Creates a Request Smuggling Boundary

HTTP/1.1 Framing Disagreement Creates a Request Smuggling Boundary An HTTP/1.1 connection can carry multiple requests in sequence. Each recipient therefore has to decide exactly where one request ends before it can parse the next. In a direct client-to-origin connection, one parser makes that decision. In a deployment with a reverse proxy, gateway, load balancer, cache, or other intermediary, the same byte stream can cross several parsers before reaching application code.

Cybersecurity HTTP

Cybersecurity / 19 Sep 2026 / 6 min read

Fetch Metadata Headers Define a Server-Side Cross-Site Request Boundary

A browser can send an authenticated request to a site from a document hosted somewhere else. Cookies may accompany that request according to their cookie attributes, while the same-origin policy can still prevent the initiating page from reading the response. For a server, that distinction matters: blocking response access does not necessarily stop a cross-site request from reaching an endpoint. Fetch Metadata adds request context to this boundary. Supporting user agents attach Sec-Fetch-* request headers that describe relationships and request properties the server can evaluate before application logic performs a sensitive action. A policy can reject a request because it is cross-site, while preserving selected navigation or public-resource flows.

Cybersecurity Web Security

Software Engineering / 19 Sep 2026 / 6 min read

ETag Preconditions Prevent Lost Writes in HTTP Update APIs

Two clients can read the same resource, edit different fields, and send updates seconds apart. If the server accepts both writes without checking which representation each client edited, the later request can silently replace state written by the earlier one. The transport succeeded, yet the application lost a concurrent change. HTTP provides a conditional request mechanism for this boundary. A server can attach an entity tag to a representation, and a client can return that tag in If-Match when submitting a state-changing request. The update proceeds only while the selected representation still satisfies the supplied precondition.

Software Engineering HTTP

JavaScript / 19 Sep 2026 / 4 min read

Axios GET Uses One Config Object for Params and Headers

axios.get() accepts a request URL and one optional configuration object. Query parameters and HTTP headers are not separate positional arguments; they are properties of that configuration object. That boundary matters because code that treats params and headers as independent config arguments either becomes invalid JavaScript or places data where Axios does not read it. The GET method has one config boundary The call shape is: axios.get(url, config) The request configuration can contain several concerns at once:

JavaScript Axios

Cybersecurity / 17 Sep 2026 / 6 min read

SameSite Cookies Enforce a Site Boundary, Not an Origin Boundary

SameSite Cookies Enforce a Site Boundary, Not an Origin Boundary An application at https://accounts.example.com uses a session cookie marked SameSite=Strict. A separate service at https://reports.example.com is operated by another team and has a distinct origin. The two hosts are isolated by the browser’s origin model for many web capabilities, yet a request from one can still be classified as same-site with the other. The cookie attribute is enforcing a site boundary, not duplicating the same-origin policy.

Cybersecurity HTTP

Cybersecurity / 17 Sep 2026 / 8 min read

HTTP Request Smuggling Begins at a Message-Framing Disagreement

HTTP Request Smuggling Begins at a Message-Framing Disagreement A reverse proxy can validate an HTTP request, route it to an approved application, and still deliver a different request sequence from the one it believed it accepted. The failure does not require the proxy to ignore authentication or the origin to execute malformed syntax. It can arise when the two HTTP processors disagree about the byte at which one request ends and the next begins.

Cybersecurity HTTP

Cybersecurity / 17 Sep 2026 / 8 min read

Fetch Metadata Exposes Browser Request Context at the Server Boundary

Fetch Metadata Exposes Browser Request Context at the Server Boundary A state-changing endpoint can receive two HTTP requests with the same method, path, cookies, and body while the browser reached them through very different contexts. One may come from the application’s own document. The other may have been triggered by a foreign site through a form, image load, navigation, or another browser mechanism that permits a request without granting the initiating page access to the response.

Cybersecurity Browser Security

Software Engineering / 16 Sep 2026 / 6 min read

Vary Expands HTTP Cache Selection Beyond the URI

Two GET requests for the same target URI can require different cached responses. If an origin selects representation metadata or content from request headers such as Accept-Encoding, a cache keyed only by the URI can return a representation selected for a different request. HTTP’s Vary response field extends cache selection across nominated request fields. It does not merely document negotiation. For a stored response carrying Vary, those nominated fields constrain whether that response can satisfy a later request without revalidation.

Software Engineering HTTP

Cybersecurity / 16 Sep 2026 / 6 min read

TLS Early Data Trades Handshake Latency for Replay Exposure

TLS Early Data Trades Handshake Latency for Replay Exposure A returning client can possess enough state from a prior TLS 1.3 connection to send application data alongside its first handshake flight. That removes a round-trip from the critical path for eligible traffic, but it also changes a security property that applications often treat as implicit: encrypted transport no longer means that a request can appear only once across connections. TLS 1.3 early data, commonly called 0-RTT, is protected using keys derived from a pre-shared key associated with an earlier session or an externally provisioned PSK. The server has not yet contributed fresh handshake state when those bytes are transmitted. As a result, early data has weaker replay properties than ordinary application data sent after the handshake.

Cybersecurity TLS

Cybersecurity / 16 Sep 2026 / 8 min read

TLS 1.3 Early Data Moves Replay Risk Into HTTP Request Semantics

TLS 1.3 Early Data Moves Replay Risk Into HTTP Request Semantics A returning client can possess a TLS 1.3 resumption ticket and send an HTTP request before a new handshake has completed. That removes a round trip from the request path, but it also changes a security property that ordinary application code often assumes: accepted encrypted traffic is not necessarily unique to one connection. TLS 1.3 early data, commonly called 0-RTT data, is protected with keys derived from a pre-shared key associated with an earlier session or provisioned out of band. The request is encrypted, yet its protection does not depend on the fresh ServerHello from the new connection. As a result, TLS does not provide the same cross-connection replay protection for early data that it provides for application data sent after the handshake.

Cybersecurity TLS 1.3

Software Engineering / 16 Sep 2026 / 7 min read

If-Range Prevents Mixed-Representation Resumes

A resumed HTTP transfer can corrupt a local result without any malformed bytes if the resource changes between requests. The first response may supply bytes from one representation while a later range response supplies offsets from another. If-Range exists to bind the resumed range to the representation that produced the stored prefix. This is a representation-identity problem rather than a transport-framing problem. Byte offsets only have stable meaning relative to a particular representation. A syntactically valid 206 Partial Content response can still be unusable for recombination when its bytes belong to a different version.

Software Engineering HTTP

Software Engineering / 16 Sep 2026 / 7 min read

If-Match Turns Stale HTTP Writes Into Precondition Failures

Two clients can read the same HTTP resource, compute different replacements, and send those replacements minutes apart. If the origin accepts both writes without a precondition, the later request can overwrite the earlier result even though it was computed from stale state. HTTP provides a protocol-level guard for this case. A client can retain an entity tag from the representation it read and send that tag in If-Match with a later state-changing request. The origin evaluates the precondition before applying the method. If no listed tag strongly matches the current selected representation, the method is not performed because of that precondition.

Software Engineering HTTP