Cybersecurity

Cybersecurity / 15 Sep 2026 / 7 min read

Certificate Transparency Turns Misissuance Into Public Evidence

Certificate Transparency Turns Misissuance Into Public Evidence A certificate authority can validate a request correctly according to its own process and still produce a certificate that a domain operator never expected. The Web PKI cannot make every issuance decision infallible, so Certificate Transparency adds a different property: public TLS certificate issuance can be recorded in logs that independent parties can inspect and audit. That distinction is central to the mechanism. Certificate Transparency does not decide whether an applicant is authorized to control a domain. It does not replace certificate validation, revocation, or DNS CAA policy. Its role is to make issuance observable and to make the log’s own history cryptographically auditable.

Cybersecurity TLS

Cybersecurity / 15 Sep 2026 / 7 min read

Certificate Transparency Makes Public TLS Issuance Auditable

Certificate Transparency Makes Public TLS Issuance Auditable A publicly trusted TLS certificate can be technically valid and still be a serious security problem. A certificate authority may issue for the wrong domain after an account compromise, validation failure, or operational error. The certificate can carry a valid signature, chain to a trusted root, and satisfy ordinary hostname checks. From the browser’s perspective, those properties alone do not reveal that the domain operator never expected the certificate to exist.

Cybersecurity Certificate Transparency

Cybersecurity / 15 Sep 2026 / 7 min read

CAA Records Constrain Public Certificate Issuance at the DNS Boundary

CAA Records Constrain Public Certificate Issuance at the DNS Boundary A public certificate can pass every browser check after issuance even if the domain operator never intended to use the certificate authority that created it. The Web PKI has several controls for detecting or responding to bad issuance, but DNS Certification Authority Authorization (CAA) acts earlier: it gives a domain holder a way to state which issuers are permitted to create certificates for a name.

Cybersecurity DNS

Cybersecurity / 14 Sep 2026 / 9 min read

WebAuthn Makes the Site Part of the Authentication Proof

A phishing page can reproduce a login screen with near-perfect visual fidelity. It can copy logos, spacing, prompts, and even the sequence of an identity provider’s screens. With a password, visual imitation can be enough: the secret typed into the counterfeit page is still a valid secret at the real service. WebAuthn changes that exchange by making site identity part of the cryptographic operation. An authenticator does not merely produce a reusable answer after a person approves a prompt. It signs data associated with the relying party and with a browser-mediated ceremony. A credential registered for one relying party is not a general credential that another site can present unchanged.

Cybersecurity WebAuthn

Cybersecurity / 14 Sep 2026 / 7 min read

WebAuthn Binds Credentials to a Web Origin

A convincing imitation of a login page can reproduce almost every visible detail of the original site. It can copy the logo, typography, form layout, error messages, and even the sequence of prompts. Password authentication gives that imitation a useful target: a secret that a person can type into the wrong origin and an attacker can relay or reuse elsewhere. WebAuthn changes that property. Its credentials are public-key pairs scoped to a relying party, and authentication produces a signed assertion tied to data supplied by the site and context supplied by the browser. The credential is not a reusable string exposed to the page. That difference moves a large part of phishing resistance from visual recognition into protocol enforcement.

Cybersecurity Web Security

Cybersecurity / 14 Sep 2026 / 8 min read

TLS Early Data Trades Latency for Replay Risk

A client reconnects to a service it visited recently and sends an HTTP request before the new TLS handshake has finished. The request can reach application processing sooner than traffic sent after handshake completion. That small latency gain is attractive at scale, but it changes a property applications often take for granted: a protected request is not automatically a fresh request. TLS 1.3 calls this feature early data, commonly described as 0-RTT data. It is available only in suitable resumed sessions, not on an initial connection with no prior session state. The client uses information associated with a previous connection to protect data sent immediately. The server can accept that data before the new handshake completes.

Cybersecurity TLS

Cybersecurity / 14 Sep 2026 / 6 min read

Subresource Integrity Pins Browser Dependencies to Expected Bytes

Subresource Integrity Pins Browser Dependencies to Expected Bytes A production page can contain no application-side injection flaw and still execute hostile JavaScript if a trusted external asset changes underneath it. The script URL may be correct, TLS may be valid, and the browser may have reached the intended host. None of those facts establish that the returned file is the exact artifact the site operator approved. Subresource Integrity, commonly shortened to SRI, adds that missing assertion for selected browser-loaded scripts and stylesheets. An integrity attribute carries one or more cryptographic digest values. After fetching the resource, the browser computes the digest of the representation used for the integrity check and refuses to apply or execute it when no supported digest matches.

Cybersecurity Subresource Integrity

Cybersecurity / 14 Sep 2026 / 6 min read

SameSite Cookies Bound Cross-Site Credential Sending

SameSite Cookies Bound Cross-Site Credential Sending A browser can send an authenticated request that the account holder never intended to make. The application may see a valid session cookie, a normal HTTP method, and a request arriving over TLS. None of those facts proves that the request originated from a page the application trusts. That gap is central to cross-site request forgery. Cookie-based sessions are ambient credentials: once stored, they can be attached by the browser according to cookie rules rather than by deliberate application code at each request. The SameSite attribute changes those rules by restricting cookie attachment in cross-site contexts.

Cybersecurity Web Security

Cybersecurity / 14 Sep 2026 / 6 min read

Rotate Session Identifiers Across Authentication Boundaries

Rotate Session Identifiers Across Authentication Boundaries A login endpoint can validate credentials perfectly and still hand an attacker an authenticated session. The failure appears when the application keeps the same session identifier before and after authentication, allowing an identifier established under anonymous conditions to survive a major increase in authority. That pattern is session fixation. It differs from session theft in an important respect: the attacker does not need to extract a secret identifier from an authenticated browser. Instead, the attacker arranges for a known identifier to become associated with a victim’s authenticated state. Once the victim signs in, possession of that already-known identifier may be enough to access the resulting session.

Cybersecurity Session Security

Cybersecurity / 14 Sep 2026 / 6 min read

Referrer Policy Controls Navigation Metadata Exposure

Referrer Policy Controls Navigation Metadata Exposure A link from an internal account page to an external support site can carry more context than the destination needs. Depending on browser policy and request conditions, the HTTP Referer header can identify the source origin or include a fuller source address. If that address contains sensitive path structure or query data, navigation metadata becomes an unintended disclosure channel. Referrer Policy gives a document, response, or individual element control over how much source address information accompanies eligible requests. It does not encrypt traffic, authenticate destinations, or prevent navigation. Its purpose is narrower: constrain the referrer information exposed when the browser makes requests.

Cybersecurity Referrer Policy

Cybersecurity / 14 Sep 2026 / 7 min read

PKCE Binds an OAuth Code to the Client That Started the Flow

An OAuth authorization code can pass through a browser, an operating-system URL dispatcher, a custom application scheme, or an application link before it reaches the client that requested it. That route is convenient, but it also means possession of the returned code is not always strong evidence that the intended client received it. Proof Key for Code Exchange, usually called PKCE, changes the value of an intercepted code. Before starting the authorization request, the client creates a high-entropy secret called the code verifier. The authorization server receives a derived code challenge with the request and later requires the original verifier when the code is exchanged for tokens. A party that captures only the authorization code lacks the second value needed to complete the exchange.

Cybersecurity OAuth

Cybersecurity / 14 Sep 2026 / 8 min read

Outbound Requests Turn Application Features Into Network Authority

A URL field can look like ordinary application input until the server acts on it. Image importers, webhook testers, document renderers, link previews, feed readers, and integration checks all have legitimate reasons to make outbound requests. The security boundary changes at the moment untrusted input influences the destination: the application is no longer processing a string; it is lending its own network position to a caller. Server-side request forgery, commonly abbreviated SSRF, emerges from that mismatch in authority. An external caller may be unable to connect to an internal service, a loopback listener, or a cloud control endpoint directly. A vulnerable server can sometimes make that connection on the caller’s behalf. Authentication at the outer application does not erase the issue. The request originates from infrastructure that downstream systems may trust for entirely separate reasons.

Cybersecurity SSRF

Cybersecurity / 14 Sep 2026 / 6 min read

OCSP Stapling Moves Revocation Evidence Closer to the TLS Handshake

OCSP Stapling Moves Revocation Evidence Closer to the TLS Handshake A browser can receive a valid certificate chain, verify every signature, confirm the hostname, and still face one more question: has the issuing certificate authority revoked the leaf certificate since it was issued? That question is awkward because the certificate itself cannot carry a fresh answer. Its signed validity interval is fixed at issuance, while revocation is an event that can happen later.

Cybersecurity TLS

Cybersecurity / 14 Sep 2026 / 6 min read

Mutual TLS Makes Client Identity Part of the Connection

A service can receive perfectly encrypted traffic from a client it should never have trusted. Ordinary server-authenticated TLS protects the channel and lets the client validate the server, but it does not automatically give the server a cryptographic identity for the caller. In machine-to-machine systems, that missing property is often filled by mutual TLS. Mutual TLS, commonly shortened to mTLS, extends the TLS handshake so that the server requests a certificate from the client. The client proves possession of the corresponding private key, and the server validates the presented certificate against an accepted trust policy. When that policy is tied to an application identity, the connection carries more than confidentiality and integrity: it also carries evidence about the peer that opened it.

Cybersecurity TLS

Cybersecurity / 14 Sep 2026 / 6 min read

HTTP Request Smuggling Exploits Parser Disagreement

HTTP Request Smuggling Exploits Parser Disagreement A reverse proxy and an application server can each parse the same byte stream according to rules that appear reasonable in isolation. Trouble starts when they reach different answers about where one request ends. Bytes treated as the tail of a request by the front end can become the start of another request at the back end, shifting the interpretation of traffic that follows on a reused connection.

Cybersecurity HTTP

Cybersecurity / 14 Sep 2026 / 7 min read

HTTP Request Framing Must Agree Across Every Hop

A reverse proxy can accept a byte sequence as one HTTP request while the application server behind it interprets part of the same sequence as the start of another. Neither component needs to contain a memory-safety defect. The security failure sits in the disagreement between their parsers. This is the central condition behind HTTP request smuggling. Modern web traffic commonly crosses several HTTP-speaking components before reaching application code: CDNs, load balancers, API gateways, service meshes, reverse proxies, and origin servers. Each hop has to determine where one request ends and the next begins. If two adjacent components derive different boundaries from the same traffic, bytes assigned to one request at the front end can acquire a different meaning downstream.

Cybersecurity Web Security

Cybersecurity / 14 Sep 2026 / 7 min read

HSTS Moves HTTPS Policy Into the User Agent

HSTS Moves HTTPS Policy Into the User Agent An HTTPS site can have a valid certificate, modern TLS settings, and a permanent redirect from HTTP, yet still expose a narrow transport-security gap before that redirect is received. If a browser begins with a plain HTTP request, the server has no opportunity to protect that request until it arrives. An attacker able to alter traffic on that path can interfere before TLS is established.

Cybersecurity HTTPS

Cybersecurity / 14 Sep 2026 / 6 min read

Filesystem Races Break the Link Between Checks and Use

A process checks that a path is safe, records a reassuring result, then opens the path a fraction of a second later. Those two operations can look like one security decision in source code. The filesystem sees two separate events, with an interval in which names, links, directories, mounts, or permissions may change. That interval is the basis of time-of-check to time-of-use races. The issue is not limited to unusually slow systems or large timing gaps. When an attacker can influence the relevant namespace concurrently, even a small gap can separate the object that passed a check from the object that receives the privileged operation.

Cybersecurity Application Security

Cybersecurity / 14 Sep 2026 / 8 min read

DNSSEC Makes DNS Answers Verifiable, Not Confidential

A resolver receives an address for a production hostname and has to decide whether the answer is merely syntactically valid or cryptographically tied to the zone that published it. Ordinary DNS provides no native proof that the data survived the path from an authoritative source without unauthorized alteration. DNSSEC changes that property, but only within a carefully defined boundary. That boundary matters in operations. DNSSEC does not encrypt a query, conceal a domain name, authenticate an application server, or guarantee that an authoritative service stays reachable. It signs DNS data so a validating resolver can detect forged or modified records when a chain of trust exists. Treating it as a broad DNS security layer obscures both its value and its failure modes.

Cybersecurity DNS

Cybersecurity / 14 Sep 2026 / 6 min read

Deserialization Can Turn Data Into Program Behavior

A serialized object can look like ordinary application data while carrying enough structure to influence which classes are instantiated, which fields receive values, and which runtime hooks execute during reconstruction. That difference matters whenever an application accepts object graphs from a browser, message queue, cache, file, or another service and treats decoding as a passive parsing operation. The dangerous cases are not defined by serialization itself. JSON decoded into a fixed record type is not equivalent to a native object stream that can name arbitrary runtime classes. The security boundary appears when attacker-controlled input can select behavior-rich types, trigger lifecycle callbacks, or assemble existing code paths into an unintended computation.

Cybersecurity Application Security

Cybersecurity / 14 Sep 2026 / 7 min read

Dangling DNS Records Can Outlive the Services They Point To

A hostname can remain part of an organisation’s public identity long after the application behind it has disappeared. The DNS record still resolves, certificates may have existed for years, links remain in old messages, and browser cookies may still be scoped broadly enough to include the name. Yet the external service named by that record may have been deleted and returned to a provider’s pool of available resources. That mismatch creates the conditions for subdomain takeover. The core problem is not DNS compromise. The authoritative zone can be operating exactly as configured. The failure sits between two control planes: DNS still delegates traffic toward an external platform, while the platform no longer associates the referenced resource with the domain owner.

Cybersecurity DNS Security

Cybersecurity / 14 Sep 2026 / 7 min read

CORS Policy Is an Authorization Boundary Between Browser Origins

A cross-origin API request can reach its destination, execute application code, and produce a valid response even when the browser refuses to expose that response to JavaScript. That distinction is central to Cross-Origin Resource Sharing, yet it is often blurred by configurations that treat CORS as a connectivity switch. CORS is a browser-enforced extension to the same-origin model. It gives a server a way to state which external origins may access selected responses from browser script. The server still owns authentication and authorization for the underlying resource. CORS controls an additional boundary: whether code running under another web origin may receive the response through browser APIs.

Cybersecurity Web Security

Cybersecurity / 14 Sep 2026 / 8 min read

Content Security Policy Works Best as an Execution Boundary

Content Security Policy Works Best as an Execution Boundary A web application can escape every obvious inline-script habit and still carry a broad execution surface. A compromised analytics host, an overly permissive script source, a reused nonce, or a policy that quietly tolerates inline code can leave the browser with far more authority than the application intended. Content Security Policy, usually delivered through the Content-Security-Policy response header, gives a site a way to constrain that authority. Its strongest role is not as a filter for hostile strings. It is a browser-enforced boundary around resource loading and script execution. That distinction matters because policies built as long host allowlists often age into something much weaker than their authors expect.

Cybersecurity Content Security Policy

Cybersecurity / 14 Sep 2026 / 7 min read

Certificate Transparency Makes Public TLS Issuance Observable

A certificate authority can issue a technically valid certificate for a domain without the domain operator being involved in that issuance. The public Web PKI is designed around many trusted authorities, and any authority accepted for a given name can potentially create a certificate that browsers will accept, subject to browser policy and certificate constraints. That broad trust model makes certificate issuance a security event worth observing, not merely an administrative transaction.

Cybersecurity TLS