Skip to content

Archive

Cybersecurity

535 articles
Cybersecurity 11 Sep 2026 10 min read

Verify Account Email Changes Before Trusting the New Address

Changing an account’s email address looks like an ordinary profile update. In many systems, though, that address is also used for password resets, security notifications, sign-in links, or account recovery. Replacing it immediately can therefore change who controls a recovery channel. The practical problem is simple: a new email address is only a claim until the application proves that the account holder can receive mail there. If the application treats the claim as trusted too early, a stolen session, typing mistake, or unsafe update flow can redirect security-sensitive messages to the wrong mailbox.

Cybersecurity 11 Sep 2026 9 min read

Validate WebSocket Origins Before Accepting Browser Connections

A WebSocket connection can stay open for minutes or hours and carry commands in both directions. If a browser automatically attaches an authenticated session to the opening handshake, a hostile web page may be able to start that connection in the user’s browser unless the server checks which site initiated it. That creates a cross-site trust problem. The user can be signed in to app.example, visit another site in a separate tab, and still have the browser make requests that involve credentials associated with app.example. A WebSocket server that accepts the handshake based only on those credentials can give an untrusted page access to an authenticated channel.

Cybersecurity 11 Sep 2026 7 min read

Validate Origin Before Trusting Browser Requests

A web endpoint can receive a valid session cookie and still receive a request that the user did not intend to send. Browsers attach cookies according to cookie rules, not according to the intent of the page that caused a request. For sensitive state changes, that distinction matters. One useful defense is to check the request’s browser origin before accepting the action. An origin identifies the scheme, host, and port of the context that initiated a request. Comparing it with a small set of expected origins can reject requests arriving from browser contexts your application does not trust.

Cybersecurity 11 Sep 2026 9 min read

Validate Host Authority Before Trusting Request Metadata

HTTP applications often need to know which host a client intended to reach. Frameworks expose that value through fields such as Host, request.host, or a parsed request authority. It can look like infrastructure metadata, but at an application boundary it is commonly influenced by the client. That distinction matters when an application uses the value for security-sensitive work. A hostile authority can affect absolute links, redirects, cache entries, tenant selection, origin checks, or routing decisions if the application accepts it without a trust policy.

Cybersecurity 11 Sep 2026 10 min read

Validate File Uploads Before They Cross a Trust Boundary

File uploads turn data supplied by another party into something your application stores, processes, and often serves back later. A profile image, invoice attachment, or imported document can therefore cross several trust boundaries in one request. The common mistake is to treat a familiar filename or a browser-supplied media type as proof of what the file contains. Those values are useful hints, but the sender controls them. If later code makes security decisions from those hints alone, an unexpected file can reach an image decoder, document parser, web server, or other component that was never meant to handle it.

Cybersecurity 11 Sep 2026 10 min read

Treat Recovery Codes as One-Time Authentication Secrets

Multi-factor authentication can lock out a legitimate user when a phone is lost, an authenticator is reset, or a security key is unavailable. Recovery codes give the user a controlled fallback. The risk is that this fallback can quietly become an easier way into the account than the authentication method it is supposed to recover. A recovery code is not just a convenience string. It is an authentication secret that may let someone bypass an unavailable factor. If an attacker obtains a valid code and the application accepts it, the application cannot tell that the person presenting it is not the legitimate user.

Cybersecurity 11 Sep 2026 7 min read

Secure Archive Extraction Against Path Traversal

Archive extraction looks simple: open a ZIP or TAR file, iterate over its entries, and write each entry under a destination directory. The dangerous detail is that archive entries carry names and, in some formats, filesystem object types. Those fields come from the archive creator. If extraction code joins an untrusted entry name to a trusted destination without enforcing containment, an entry such as ../../app/config.json can escape the intended directory. A crafted archive can then overwrite files that the application account is permitted to modify.

Cybersecurity 11 Sep 2026 8 min read

Reject Duplicate JSON Keys at Security Boundaries

JSON looks simple enough that teams often treat parsing as a solved problem. A payload arrives, a library turns it into an object, validation runs, and the application uses the result. That model breaks when an object contains the same member name more than once. Different parsers, frameworks, gateways, signature layers, and application components can resolve duplicate names differently. One component may keep the first value, another may keep the last, and another may reject the payload. If a security decision is made using one interpretation and an action is performed using another, the gap becomes a security boundary failure.

Cybersecurity 11 Sep 2026 10 min read

Reject Ambiguous HTTP Request Framing

A reverse proxy and an application server can both accept the same HTTP connection and still disagree about where one request ends and the next begins. That disagreement is more than a parsing bug. On a reused connection, bytes that one component treats as part of a request can be interpreted by another component as the start of a second request. This class of problem is called HTTP request smuggling, or more generally HTTP desynchronization. The practical defensive goal isn’t to recognize every historical attack variation. It is to make request boundaries unambiguous at every hop, reject malformed framing instead of guessing, and test the exact proxy-to-backend path that production traffic uses.

Cybersecurity 11 Sep 2026 9 min read

Publish a security.txt File for Vulnerability Reports

A security flaw can be reported only if the person who finds it can locate a usable reporting route. When that route is buried in a support portal, points to an abandoned mailbox, or varies across domains, a valid report can be delayed or sent to the wrong place. security.txt gives a web service a standard place to publish vulnerability-reporting contact details. The file is deliberately small. Its value comes from making the route predictable and keeping the route operational.

Cybersecurity 11 Sep 2026 9 min read

Plan Certificate Revocation Before a Key Is Compromised

A TLS certificate can still be inside its validity period when you need clients to stop trusting it. The private key may have been exposed, an identity may no longer be valid, or an issuing system may have made a serious mistake. Waiting for the certificate to expire leaves a gap between “we know this credential should no longer be trusted” and “clients stop accepting it.” Certificate revocation is the mechanism for communicating that change before normal expiry. The difficult part is operational: revocation information has to reach the relying parties that make trust decisions, and their behaviour when that information is stale or unavailable may differ.

Cybersecurity 11 Sep 2026 8 min read

Pin JWT Verification to Approved Algorithms

A JSON Web Token can carry identity and authorization claims across service boundaries. Its compact format also carries a header that describes cryptographic processing, including an alg field. That field comes from the token itself. It is attacker-controlled input until verification succeeds. A verifier therefore must not treat alg as permission to select any cryptographic mode a library happens to support. The application must decide which algorithm, key type, issuer, audience, and other verification rules are acceptable. The token may identify a candidate within that fixed policy, but it must not define the policy.

Cybersecurity 11 Sep 2026 9 min read

Manage Concurrent Sessions Without Breaking Legitimate Use

A user signs in on a laptop, then on a phone, and later on a work computer. All three sessions may be legitimate. If one device is lost or a session token is stolen, though, the same account can also have a session the user no longer controls. A simple rule such as “allow only one login at a time” looks like a security control, but it mixes two different questions: how many sessions exist, and whether each session is still trustworthy. Strict concurrency limits can disrupt legitimate users while doing little to identify the session that actually needs to be removed.

Cybersecurity 11 Sep 2026 9 min read

Keep Untrusted Data from Forging Log Entries

Security logs are useful only when their records mean what investigators and monitoring systems think they mean. A login failure, permission change, or rejected request may contain values supplied by a client. If an application simply joins those values into a line of log text, special characters can blur the boundary between the application’s event and the data inside it. That problem is called log injection or log forging. The defensive goal isn’t to remove every unusual character from user input. It is to make sure untrusted data remains data when it reaches the logging format. This article develops that mental model, shows why structured logging helps, and explains what still needs attention after the event boundary is protected.

Cybersecurity 11 Sep 2026 9 min read

Keep TLS Certificate Verification Enabled

An HTTPS client does more than encrypt bytes. During the TLS handshake, it also checks evidence about the server’s identity. If application code disables those checks, the connection can remain encrypted while being connected to an unintended endpoint. That distinction is central to secure TLS use. Encryption protects data against passive observation, but authenticated encryption to the wrong peer does not establish the identity the application intended to contact. The practical rule is: keep certificate-chain and hostname verification enabled, and repair trust configuration instead of bypassing verification.

Cybersecurity 11 Sep 2026 9 min read

Keep Bearer Tokens Out of URLs

A bearer token grants access to whoever presents it successfully. That makes its storage and transport path part of the authentication design. If an application places such a token in a URL, the credential can travel into systems that were built to record or process URLs rather than protect secrets. The immediate request may still use HTTPS. The problem is what happens around that request: server access logs, reverse proxies, monitoring tools, browser history, support captures, and analytics pipelines can all handle URL data. A token copied into those places gains more exposure paths and can remain there long after the request finishes.

Cybersecurity 11 Sep 2026 8 min read

Enforce HTTPS with HTTP Strict Transport Security

TLS protects an HTTP connection after the browser has chosen HTTPS and completed certificate validation. A separate problem exists before that protected connection begins: a user can type a bare hostname, follow an old HTTP link, or reach a page that redirects from HTTP to HTTPS. HTTP Strict Transport Security, usually called HSTS, lets a site tell supporting browsers to treat future connections to that host as HTTPS-only. The browser stores the policy for a defined period. While the policy is active, an HTTP navigation is upgraded locally before an insecure HTTP request is sent.

Cybersecurity 11 Sep 2026 8 min read

Encode Untrusted Data Before Writing Security Logs

Security logs often contain values that originated outside the trust boundary: usernames, request paths, HTTP headers, device names, search terms, object identifiers, and error details. Those values can be useful during incident response, but they can also become an attack surface when an application inserts them into log records without safe encoding. A malicious value containing line breaks or terminal control data can distort a text log, create a record that appears to come from the application, or make an analyst misread the sequence of events. The same input can also cause trouble farther downstream when collectors and parsers disagree about record boundaries.

Cybersecurity 11 Sep 2026 10 min read

Do Not Build Security Links from Untrusted Host Headers

Applications often need to send absolute URLs. A password reset email, account verification message, or administrative invitation needs a link such as https://accounts.example/reset?..., not just /reset?.... A tempting implementation takes the hostname from the current HTTP request and attaches the security-sensitive path. That works in ordinary testing, but it confuses two different facts: where the request says it was addressed and which public origin the application trusts for security links. If an untrusted request can influence the first value, it may influence a link containing a secret token.

Cybersecurity 11 Sep 2026 8 min read

Disable External Entities in XML Parsers

XML is a data format, but an XML parser can have capabilities that go far beyond reading elements and attributes. Depending on its configuration, a parser may process document type declarations, expand entities, access local files, or make network requests. Those capabilities can turn a data-processing boundary into a file-access or network-access boundary. An application that accepts XML from an untrusted source must therefore control parser features before parsing begins.

Cybersecurity 11 Sep 2026 9 min read

Design Shared Cache Keys Around Response Variance

Shared HTTP caches can reduce latency and origin load, but they also introduce a security boundary. A cache stores a response produced for one request and may later serve that response to another request. That reuse is correct only when both requests are equivalent for every property that can affect the response. A dangerous configuration appears when an origin varies its response on a request property that the shared cache does not include in cache selection. An attacker can send a crafted request, cause the origin to generate attacker-influenced content, and leave that content stored under a key that ordinary visitors also use.

Cybersecurity 11 Sep 2026 8 min read

Contain Archive Extraction Within an Approved Directory

Extracting an uploaded ZIP or TAR file can look like a routine file operation: read each archive entry, join its name to an output directory, then write the contents. The security boundary is hidden in that middle step. An archive controls its entry names, and a careless extractor can let those names select files outside the intended destination. The result can be more serious than a misplaced file. If the process can write to application configuration, startup files, web content, or another user’s data, an archive upload may become an unintended filesystem write primitive.

Cybersecurity 11 Sep 2026 7 min read

Compare Secret Values in Constant Time

A server often needs to decide whether an untrusted value matches a secret value it already knows. Examples include verifying a message authentication code (MAC), checking a high-entropy API token, or validating a signed-request tag. A normal equality operation may stop as soon as it finds a different byte. That behavior is efficient, but the amount of work can then depend on where the first difference appears. Under suitable conditions, repeated timing observations can expose information about the secret comparison.

Cybersecurity 11 Sep 2026 9 min read

Bound Password Verification Work to Resist Resource Exhaustion

Password hashing is intentionally expensive. That cost makes each offline password guess more expensive after a verifier database is stolen. The same property creates an operational risk on a live login endpoint: an unauthenticated client can ask the server to perform costly password verification again and again. A service that treats every login attempt as unlimited work can exhaust CPU, memory, worker slots, or downstream capacity before an attacker needs a valid account. The defensive goal is not to make password hashing cheap. It is to preserve a suitable password-hashing cost while placing firm limits around how much verification work the service will accept at once.