Cybersecurity

Cybersecurity / 20 Sep 2026 / 6 min read

Webhook HMAC Signatures Need Replay Controls

Webhook HMAC Signatures Need Replay Controls A webhook receiver often needs to decide whether an HTTP request came from a configured sender and whether the payload changed in transit. A keyed message authentication code can support that decision when both sides share a secret and compute the tag over the same bytes. That property does not make a captured request single-use. If an attacker records a valid request and submits the same authenticated material again, the tag can remain valid. Replay resistance therefore has to be part of the webhook protocol around the MAC, not an assumption attached to the MAC itself.

Cybersecurity Webhooks

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 / 6 min read

TLS SPKI Pinning Needs a Rotation Path

TLS SPKI Pinning Needs a Rotation Path Certificate pinning adds a local trust constraint to the certificate checks already performed by a TLS client. Instead of accepting any certificate that satisfies the configured PKI and service-identity rules, a pinned client also requires the connection to present cryptographic material that matches a value already embedded in, provisioned to, or otherwise trusted by the client. That narrower policy can reduce exposure to certificate issuance outside the intended key set. It also creates a new operational dependency: the client must carry a valid path from the key accepted today to a key that can be used after rotation.

Cybersecurity TLS

Cybersecurity / 20 Sep 2026 / 6 min read

TLS Hostname Verification Binds a Valid Certificate to the Requested Name

TLS Hostname Verification Binds a Valid Certificate to the Requested Name A TLS certificate can be cryptographically valid and still be wrong for the server a client intended to reach. Chain validation answers whether the certificate can be linked to a configured trust anchor under the applicable PKI rules. Service identity verification answers a separate question: whether that certificate represents the hostname the client requested. Both checks are required for ordinary HTTPS authentication. Accepting a trusted certificate without checking the requested name turns a narrow credential into a credential for unrelated destinations.

Cybersecurity TLS

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

Cybersecurity / 20 Sep 2026 / 7 min read

TLS 1.3 Session Tickets Carry Resumption State Across Connections

TLS 1.3 Session Tickets Carry Resumption State Across Connections A completed TLS 1.3 handshake can establish more than traffic keys for the connection that is already open. After the handshake, a server can issue a NewSessionTicket that gives the client material for a later resumption attempt. The later connection can then authenticate continuity with the earlier TLS session without repeating the same certificate-based handshake path. That optimization changes where security state lives. A deployment that enables resumption is no longer concerned only with the server certificate and the keys of the current connection. Ticket lifetime, resumption secrets, cached authentication attributes, ticket protection keys, and the rules used when accepting a resumed connection become part of the boundary.

Cybersecurity TLS 1.3

Cybersecurity / 20 Sep 2026 / 5 min read

Subresource Integrity Pins Browser Execution to Expected Bytes

Subresource Integrity Pins Browser Execution to Expected Bytes A web page can fetch JavaScript and stylesheets from infrastructure outside the application’s deployment boundary. A CDN improves distribution, but the browser normally treats the response from the referenced URL as the resource the page requested. If that response changes unexpectedly, transport security alone does not tell the browser that the bytes differ from the version selected by the application operator. Subresource Integrity (SRI) adds a content check to that load. The page carries cryptographic metadata for an expected representation. A supporting browser hashes the fetched resource and accepts it only when the result satisfies the declared integrity metadata.

Cybersecurity Subresource Integrity

Cybersecurity / 20 Sep 2026 / 5 min read

SSH User Certificates Bind CA Trust to Principals

SSH User Certificates Bind CA Trust to Principals Managing SSH access with individual public keys is straightforward at small scale. Each server can keep a list of accepted keys in authorized_keys. As the number of people and hosts grows, however, access control also becomes a key-distribution problem: adding, rotating, and removing identities requires changes across the machines that trust them. OpenSSH user certificates provide a different trust model. A server can trust a user certification authority (CA), then accept user certificates signed by that CA when the certificate also satisfies the server’s authentication policy. The CA signature answers only part of the decision. Principals, validity intervals, certificate options, and server configuration determine where and how the signed key may be used.

Cybersecurity OpenSSH

Cybersecurity / 20 Sep 2026 / 6 min read

Session ID Rotation Closes the Pre-Authentication Session Gap

Session ID Rotation Closes the Pre-Authentication Session Gap A web application can assign a session before a user signs in. That anonymous session may hold a CSRF token, locale, shopping state, or other temporary data. Authentication changes the authority attached to the session: the server now treats requests carrying that session as belonging to an identified account. If the application keeps the same session identifier across that transition, a value established before authentication can become the handle for an authenticated session. Session fixation attacks target that continuity. The defensive boundary is the authentication event itself: preserve only the state that should survive, issue a fresh unpredictable identifier, and retire the old identifier.

Cybersecurity Authentication

Cybersecurity / 20 Sep 2026 / 6 min read

SameSite Cookies Reduce Cross-Site Request Attachment

SameSite Cookies Reduce Cross-Site Request Attachment Cookie-based sessions rely on browser behavior that is both useful and security-sensitive: once a cookie matches a request’s domain, path, security, and other applicable rules, the browser can attach it without application code explicitly supplying the credential. That ambient behavior makes sessions convenient, but it also creates a channel through which a request initiated from another site can arrive with authentication state. The SameSite cookie attribute narrows that channel. It tells the browser whether a cookie may accompany requests whose site context differs from the cookie’s site. The control changes credential attachment at the browser boundary; it does not turn a state-changing endpoint into an authorized operation by itself.

Cybersecurity Cookies

Cybersecurity / 20 Sep 2026 / 5 min read

SameSite Cookies Make Site Context Part of Session Delivery

SameSite Cookies Make Site Context Part of Session Delivery HTTP cookies are ambient credentials in many web applications. Once a browser stores a session cookie, matching requests can carry it automatically; application code does not have to attach the credential to every request. That convenience also creates a security problem: a page on another site may cause the browser to issue a request to the authenticated application. The SameSite cookie attribute adds request context to the browser’s delivery decision. A cookie can still match its domain, path, expiry, and transport requirements, yet be withheld because the request is cross-site. The control therefore changes where part of the session boundary is enforced: before the credential reaches the server.

Cybersecurity Cookies

Cybersecurity / 20 Sep 2026 / 6 min read

Password Reset Links Need a Trusted Public Origin

Password Reset Links Need a Trusted Public Origin A password reset email often contains one of the most sensitive URLs an application creates. Possession of a valid reset token may be enough to establish a new credential for the associated account, so the destination embedded in that URL is part of the security boundary. A common implementation mistake is to construct the absolute reset URL from host information carried by the incoming HTTP request. Headers such as Host exist for request routing, and deployments behind proxies may also expose forwarded host or scheme metadata. Unless the application has explicitly established which intermediary is trusted and which values are valid, that request metadata is not a safe source of authority for a security-sensitive outbound link.

Cybersecurity Authentication

Cybersecurity / 20 Sep 2026 / 7 min read

OCSP Stapling Moves Certificate Status Delivery into the TLS Handshake

OCSP Stapling Moves Certificate Status Delivery into the TLS Handshake A valid certificate chain answers an important TLS question: can the presented public key be linked through trusted issuers to the requested identity? It does not, by itself, say that an unexpired certificate is still acceptable to its issuer. Revocation mechanisms address that separate state. The Online Certificate Status Protocol (OCSP) allows a relying party to request status for a certificate from an OCSP responder. OCSP stapling changes who transports that status. Instead of requiring each client to contact the responder during connection setup, the TLS server can obtain a signed OCSP response and attach it to the handshake.

Cybersecurity TLS

Cybersecurity / 20 Sep 2026 / 6 min read

mTLS Client Certificates Authenticate the Peer, Not the Policy

mTLS Client Certificates Authenticate the Peer, Not the Policy Mutual TLS adds client authentication to the TLS handshake. The server presents its certificate as usual, and the client also presents a certificate when the server requests one. A successful handshake can establish that the connecting peer possesses the private key corresponding to an accepted certificate chain. That result is valuable, but it is narrower than application authorization. A valid certificate does not by itself state which tenant, API operation, database row, administrative action, or service capability the peer may use. Those decisions belong to a policy layer that consumes authenticated certificate identity.

Cybersecurity mTLS

Cybersecurity / 20 Sep 2026 / 5 min read

mTLS Client Certificates Authenticate Peers, Not Permissions

mTLS Client Certificates Authenticate Peers, Not Permissions Mutual TLS adds client authentication to a TLS connection. The server requests a certificate, validates the presented certificate according to its configured trust policy, and obtains authenticated certificate information before application data is accepted over that connection. That result is useful, but narrower than an authorization decision. A valid client certificate can establish that a peer possesses a private key associated with an accepted certificate. It does not, by itself, state which API methods, tenant records, administrative operations, or service resources that peer may use.

Cybersecurity mTLS

Cybersecurity / 20 Sep 2026 / 6 min read

JWT Audience Checks Keep Tokens Inside Their Intended Service Boundary

JWT Audience Checks Keep Tokens Inside Their Intended Service Boundary A valid JSON Web Token signature proves a narrow fact: the token bytes were signed with a key accepted by the verifier and were not modified afterward without invalidating that signature. That result does not establish that the token was issued for the service currently receiving it. This distinction matters in systems where one authority issues tokens for several APIs, or where multiple authorities use keys that an application can reach through configuration. A token can be cryptographically valid yet belong to a different security context. The iss and aud claims give the verifier inputs for enforcing that boundary.

Cybersecurity JWT

Cybersecurity / 20 Sep 2026 / 5 min read

HSTS Pins HTTPS Policy to the Browser

HSTS Pins HTTPS Policy to the Browser Redirecting HTTP traffic to HTTPS is useful, but a redirect is still an HTTP response. A browser that starts with http://example.com has already sent an unauthenticated request before the server can answer with 301 or 308. An attacker able to modify that connection can suppress or replace the redirect. HTTP Strict Transport Security (HSTS) moves part of the transport policy into the browser. After receiving a valid Strict-Transport-Security header over HTTPS, a supporting browser remembers that the host requires secure transport for the declared lifetime. Later attempts to use HTTP for that host are upgraded locally before an HTTP request is sent.

Cybersecurity HSTS

Cybersecurity / 20 Sep 2026 / 6 min read

Fetch Metadata Headers Gate Cross-Site Requests

Fetch Metadata Headers Gate Cross-Site Requests A web server often receives enough HTTP information to route a request but not enough to tell what browser context produced it. A GET might be a top-level navigation, an image load, or a JavaScript fetch. A POST might come from the application’s own page or from a form hosted on another site. Fetch Metadata adds browser-generated request headers that describe that context. Sec-Fetch-Site reports the relationship between the initiator and target, while Sec-Fetch-Mode, Sec-Fetch-Dest, and in some cases Sec-Fetch-User describe the request mode, destination, and user activation. A server can use those signals to reject request shapes that an endpoint has no reason to accept.

Cybersecurity Web Security

Cybersecurity / 20 Sep 2026 / 7 min read

DPoP Binds OAuth Access Tokens to a Client Key

DPoP Binds OAuth Access Tokens to a Client Key A bearer access token is usable by any party that obtains the token and can present it to the resource server. TLS protects the token while it crosses a correctly authenticated connection, but it does not change that bearer property after the token reaches an endpoint, log, process, browser context, or other storage location. Demonstrating Proof of Possession (DPoP), specified by RFC 9449, adds a key-bound layer at the application protocol. The client creates an asymmetric key pair and signs a DPoP proof JWT. An authorization server can bind an issued access token to the public key represented by that proof. The resource server then requires both the token and a valid proof created with the corresponding private key.

Cybersecurity OAuth

Cybersecurity / 20 Sep 2026 / 8 min read

DNS Rebinding Turns Name Validation into a Time-of-Use Risk

DNS Rebinding Turns Name Validation into a Time-of-Use Risk An outbound HTTP feature may appear safe after it rejects literal loopback and private IP addresses. The service parses a user-supplied URL, resolves its hostname, checks the returned address against an allowlist, then lets the HTTP client open the connection. Those steps contain a gap. The policy decision applies to an address observed at one moment, while the network connection may perform another DNS lookup later. If the hostname is controlled by an attacker, its DNS answers can change between those events. The validated name stays identical while the destination address changes.

Cybersecurity DNS

Cybersecurity / 20 Sep 2026 / 6 min read

DNS CAA Narrows Which Certificate Authorities May Issue for a Domain

DNS CAA Narrows Which Certificate Authorities May Issue for a Domain Publicly trusted TLS certificates are issued by certificate authorities that satisfy browser and operating-system trust requirements. A domain operator normally chooses one CA, but the public trust ecosystem can contain many authorities capable of issuing certificates that clients would accept. Certification Authority Authorization (CAA) records add a DNS policy at issuance time. A domain can state which CAs are permitted to issue certificates for it. RFC 8659 defines the processing model, including record lookup, property tags, and issuer behavior.

Cybersecurity DNS

Cybersecurity / 20 Sep 2026 / 6 min read

CSP Nonces Bind Script Execution to Server-Selected Markup

CSP Nonces Bind Script Execution to Server-Selected Markup A Content Security Policy (CSP) can restrict which scripts a browser executes. Host-based source lists are one way to express that restriction, but a permitted host is a coarse trust boundary: any script resource matching the allowed source can satisfy that part of the policy. A nonce-based policy changes the unit of authorization. The server generates an unpredictable nonce for a response, places the nonce in the script-src policy, and attaches the same value only to script elements selected for execution. The browser compares those values when applying CSP.

Cybersecurity Content Security Policy

Cybersecurity / 20 Sep 2026 / 5 min read

CSP Nonces Bind Script Execution to Each Response

CSP Nonces Bind Script Execution to Each Response Content Security Policy can restrict which scripts a browser executes after receiving a document. A nonce-based policy moves that decision away from a broad host allowlist: the server places a fresh unpredictable value in the response policy and copies that value only onto script elements it intends to authorize. The mechanism is narrow. A nonce does not sanitize HTML, prove that a script is benign, or repair an unsafe DOM API. It gives the browser an authorization token for selected script elements in one document response.

Cybersecurity Content Security Policy

Cybersecurity / 20 Sep 2026 / 6 min read

Certificate Transparency Makes Misissuance Publicly Auditable

Certificate Transparency Makes Misissuance Publicly Auditable A browser can validate a TLS certificate chain and still face a structural PKI problem: a trusted certification authority may have issued another valid certificate for the same domain without the domain operator expecting it. Ordinary path validation checks the certificate presented on the current connection. It does not provide a global inventory of certificates issued elsewhere. Certificate Transparency (CT) adds a public audit trail. Public TLS certificates or precertificates can be submitted to CT logs, which maintain append-only Merkle trees. A log that accepts a submission returns a Signed Certificate Timestamp (SCT), a signed commitment associated with that entry. Monitors can inspect log contents for certificates of interest, while auditors can check inclusion and consistency evidence.

Cybersecurity TLS