Cybersecurity

Cybersecurity / 11 Sep 2026 / 8 min read

Block Clickjacking with an Explicit Framing Policy

A sensitive web page can have sound authentication and authorization yet still be exposed through another site’s interface. If an attacker can place that page inside a transparent or disguised frame, a signed-in user may believe they are clicking one control while their click reaches a different control in the framed application. That attack class is clickjacking, also called UI redressing. The browser is doing what both pages request; the security failure is that the sensitive application allowed an untrusted page to become part of its user interface.

Cybersecurity Web Security

Cybersecurity / 10 Sep 2026 / 10 min read

Validate JWTs for the Context That Will Use Them

A service receives a JSON Web Token, verifies its signature successfully, reads the user identifier, and accepts the request. That sounds reasonable, but one question is still unanswered: was this token issued for this service and this purpose? A valid signature proves something narrow. Under the expected cryptographic scheme and key, it shows that the protected token content has not been changed since it was signed by whoever controls that signing key. It does not by itself prove that your API is an intended recipient, that the token is still within its accepted lifetime, or that a token created for one workflow should be accepted by another.

Cybersecurity Authentication

Cybersecurity / 10 Sep 2026 / 8 min read

Use Password Managers as a Phishing Signal

A phishing page can copy a real login screen closely enough that visual inspection is unreliable. The logo, wording, colours, and layout may all look familiar while the page is hosted somewhere the legitimate service does not control. If a user types a password there, the look of the page has done nothing to protect the credential. A password manager can add a different kind of signal. Instead of deciding from appearance alone, it can associate a saved credential with the website where that credential belongs and offer it only when its matching rules are satisfied. When a familiar login page appears but the expected credential is not offered, that mismatch can be a reason to stop and inspect the destination before entering anything.

Cybersecurity Authentication

Cybersecurity / 10 Sep 2026 / 10 min read

Treat Uploaded File Types as Untrusted Input

A file upload usually arrives with reassuring metadata: a filename ending in .png, a Content-Type: image/png field, and perhaps a browser that already filtered the file picker to images. None of those facts proves that the uploaded bytes are a valid PNG image. That distinction matters as soon as the server does something security-sensitive with the file. It may pass the bytes to an image decoder, extract an archive, generate a preview, or serve the file to another user. If the application chooses that behavior from attacker-controlled metadata, it can send unexpected data into a parser or return active content under the wrong assumptions.

Cybersecurity Secure Coding

Cybersecurity / 10 Sep 2026 / 12 min read

Treat MFA Recovery Codes as Real Credentials

Multifactor authentication can fail for ordinary reasons: a phone is lost, a hardware key breaks, or a device is replaced before an authenticator is migrated. Recovery codes give users a way back into an account without asking support staff to improvise an identity check. That convenience creates a security boundary of its own. If a recovery code can bypass the normal second factor, anyone who obtains that code may be able to do the same. A recovery system that is easier to attack than the authentication it replaces can quietly become the preferred path into the account.

Cybersecurity Authentication

Cybersecurity / 10 Sep 2026 / 9 min read

Require Independent Approval for High-Risk Administrative Actions

Some administrative actions are too consequential to depend on one account making one decision. An administrator might be compromised, might misunderstand the target, or might simply select the wrong option. If that one identity can immediately disable a critical control, grant powerful access, or approve a destructive change, ordinary authentication cannot distinguish a legitimate decision from a costly mistake. Independent approval changes that failure mode. One authorized person proposes the action, and a different authorized person must approve the same action before it can execute. The control is sometimes called two-person approval or a four-eyes rule. Its useful security property is narrower than those names suggest: a single administrator’s authority is insufficient for a defined class of high-risk operations.

Cybersecurity Access Control

Cybersecurity / 10 Sep 2026 / 10 min read

Reject Replayed Sensitive Requests with Freshness and Uniqueness

A request can be authentic and still be unsafe to execute twice. Suppose a service accepts a correctly authenticated instruction to change a payout destination, approve a privileged action, or trigger another sensitive operation. If someone can capture that valid request and submit the same authenticated message again, checking its credentials or signature a second time may produce the same answer: the request is genuine. The server still needs to decide whether it is current and whether it has already been used.

Cybersecurity Authentication

Cybersecurity / 10 Sep 2026 / 10 min read

Rate Limit Login Attempts Without Creating Easy Lockouts

A login endpoint has to accept wrong passwords. Users mistype them, password managers can hold stale credentials, and old devices sometimes retry automatically. An attacker can use the same interface to make thousands of guesses unless the application limits how quickly authentication can be attempted. The obvious fix is to lock an account after several failures. That slows guessing, but it creates another problem: anyone who knows a username may be able to keep that user locked out by deliberately submitting bad passwords.

Cybersecurity Authentication

Cybersecurity / 10 Sep 2026 / 10 min read

Rate Limit Login Attempts Without Creating a Lockout Weapon

A login endpoint has an awkward property: before authentication succeeds, it must accept requests from people whose identity it hasn’t proved yet. That makes it a natural target for automated password guessing. If the endpoint allows unlimited attempts, an attacker gets unlimited opportunities to try credentials. If it permanently locks an account after a few failures, the attacker may be able to lock out the legitimate user instead. Login rate limiting is the middle ground. It reduces how quickly repeated authentication attempts can be made, but the design matters. A useful limiter needs to constrain attacks aimed at one account, attacks coming from one source, and distributed attacks without turning every false positive into a long outage.

Cybersecurity Authentication

Cybersecurity / 10 Sep 2026 / 9 min read

Pin Third-Party Browser Assets with Subresource Integrity

Loading JavaScript directly from another organisation’s server creates a security dependency that is easy to overlook. Your page may contain only a short <script> tag, but the downloaded file executes with the privileges that your site gives that script. If the file at that URL changes unexpectedly, your users can receive code you never reviewed or deployed. Subresource Integrity (SRI) gives the browser an expected cryptographic hash for a fetched resource. The browser hashes the bytes it receives and loads the resource only when the result matches the declared value. That turns “load whatever this URL serves” into “load the specific content I approved from this URL.”

Cybersecurity Software Supply Chain

Cybersecurity / 10 Sep 2026 / 10 min read

Limit Decompression Before Untrusted Data Exhausts Resources

A service may reject a 100 MB upload and still accept a much smaller compressed file that expands far beyond the memory or storage the service can afford. The upload limit measured the bytes crossing one boundary. The expensive work happens after that boundary, when the application decompresses, parses, indexes, scans, or stores the expanded data. This is the practical problem behind decompression bombs: compact input can cause disproportionate resource use when software expands it without enforcing a budget on the result. The consequence is usually availability loss rather than unauthorized access. Workers can run out of memory, temporary storage can fill, CPU time can be consumed, and a queue of expensive jobs can delay ordinary requests.

Cybersecurity Secure Coding

Cybersecurity / 10 Sep 2026 / 10 min read

Keep User-Controlled Redirects on Trusted Destinations

Login flows often need to remember where a user was going. A request arrives for /billing, the application sends the user to sign in, then redirects them back after authentication. The feature is useful, but it becomes an open redirect when an untrusted value can make the application send the browser to an arbitrary destination. That matters because the redirect begins on a domain the user already trusts. A crafted link can legitimately reach your application and then immediately send the browser somewhere you never intended. Redirect parameters can also cross security boundaries in authentication and authorization flows when code assumes that “after login” is automatically a trusted place.

Cybersecurity Web Security

Cybersecurity / 10 Sep 2026 / 8 min read

Keep Untrusted Redirects on Your Own Origin

A login page often needs to remember where a user was going. After authentication, the application might read a next or return_to parameter and send the browser there. The feature looks harmless because the redirect happens only after the application has finished its real work. The problem appears when that parameter can name any destination. An attacker can then distribute a link on your trusted domain that immediately sends visitors somewhere the attacker chose. This is an open redirect: untrusted input controls the destination of an HTTP redirect without a sufficiently strict destination policy.

Cybersecurity Secure Coding

Cybersecurity / 10 Sep 2026 / 9 min read

Keep Untrusted Data Out of Native Object Deserializers

A convenient serializer can turn an object graph into bytes and later rebuild it with one function call. That convenience becomes a security problem when the bytes come from a request, message, uploaded file, cache entry, or other source an attacker can influence. Some native object formats carry more than plain values: they can encode types, object relationships, or instructions that cause application-defined behavior during reconstruction. If an application treats such input as ordinary data, parsing may cross a trust boundary before validation gets a chance to help. The result can range from unexpected object state to dangerous code paths, depending on the serialization system and the classes available to it.

Cybersecurity Secure Coding

Cybersecurity / 10 Sep 2026 / 8 min read

Keep Untrusted Data from Forging Log Events

Security logs often contain untrusted data: usernames, request paths, user-agent strings, filenames, API parameters, and error details. Recording those values is useful, but treating them as preformatted log text can blur the boundary between what happened and data supplied by the requester. If an attacker-controlled value can create what looks like another log record, an investigator or automated parser may misread fabricated text as an event produced by the application. This is commonly called log injection or log forging.

Cybersecurity Secure Coding

Cybersecurity / 10 Sep 2026 / 8 min read

Keep Private Responses Out of Shared Caches

A cache can make a web application faster by reusing a response instead of asking the application to generate it again. That becomes a security problem when the reused response contains data for one particular user. If a shared cache stores a personalized account page under a key that does not distinguish users, a later requester may receive the first user’s response. Authentication at the application can be perfectly correct and the data can still cross an authorization boundary because the second request never reaches that application logic.

Cybersecurity Web Security

Cybersecurity / 10 Sep 2026 / 10 min read

Do Not Bind Web Sessions to IP Addresses

A stolen session cookie can let someone use an account without knowing the user’s password. That makes a simple defense sound attractive: remember the IP address used at login and reject the session whenever the address changes. The problem is that an IP address is usually a property of the user’s current network path, not a stable property of the user or device. Legitimate addresses change, while different people can share one address. Strict IP binding can therefore lock out real users without reliably stopping an attacker.

Cybersecurity Authentication

Cybersecurity / 10 Sep 2026 / 9 min read

Design Push MFA to Resist Approval Fatigue

A push notification can make multi-factor authentication feel effortless: enter a password, tap Approve on a registered device, and continue. The same convenience creates a problem when the approval prompt does not require the user to prove which login they are approving. If an attacker obtains a password and can repeatedly trigger MFA requests, the legitimate user may receive prompts they did not initiate. A tired, distracted, or confused user may eventually approve one. This is commonly called MFA fatigue or push fatigue.

Cybersecurity Authentication

Cybersecurity / 10 Sep 2026 / 9 min read

Design Audit Logs That Remain Useful After Compromise

An application can record every error and still have little evidence when an account is abused. Ordinary operational logs answer questions such as “why did this request fail?” Security investigations need different facts: which identity changed an authentication factor, which administrator granted access, which object was affected, and whether the action succeeded. That is the job of an audit log: a durable record of security-relevant actions and decisions. A useful audit log helps investigators reconstruct events after an incident while limiting two risks of its own: attackers changing the evidence and sensitive data leaking through the log.

Cybersecurity Security Logging

Cybersecurity / 10 Sep 2026 / 10 min read

Consume One-Time Security Tokens Atomically

A password-reset link may be described as “single use”, yet two requests arriving almost together can both see the token as unused. If each request then continues independently, the application can perform a security-sensitive action twice even though its data model contains a used flag. This is a concurrency problem with security consequences. The same pattern can affect account invitations, email-verification links, recovery codes, approval links, and other credentials that are supposed to grant authority once.

Cybersecurity Authentication

Cybersecurity / 10 Sep 2026 / 11 min read

Constrain Server-Side URL Fetching to Prevent SSRF

Applications often fetch URLs supplied indirectly by users. A link-preview service retrieves a page, an image importer downloads an avatar, or a webhook tester sends a request to a configured endpoint. The feature may look like ordinary URL handling, but it gives the requester influence over a network connection made with the application’s identity and network access. If that influence is too broad, the application can become a route to destinations the requester could not reach directly. This class of weakness is server-side request forgery, usually shortened to SSRF.

Cybersecurity Secure Coding

Cybersecurity / 10 Sep 2026 / 10 min read

Confine Archive Extraction to Its Destination

Extracting an archive looks like a simple file operation: read each entry, join its name to an output directory, and write the result. The dangerous part is that an archive controls those entry names. If extraction code treats them as trusted relative paths, a crafted entry can make a write escape the directory chosen by the application. That failure is commonly called archive path traversal. It can turn an upload, package import, backup restore, or document-processing feature into an unintended filesystem write. The consequence depends on the extractor’s permissions: files outside the extraction area may be created or replaced, including files later consumed by other parts of the system.

Cybersecurity Secure Coding

Cybersecurity / 10 Sep 2026 / 8 min read

Bound Decompression Before Processing Untrusted Data

A compressed request or uploaded archive can look harmless when its byte count is small. The server may discover a very different workload after decompression: far more output bytes, memory use, disk writes, or nested work than the original input suggested. That gap matters whenever an attacker can supply compressed data. If the application limits only the compressed input size, a small request can still force expensive expansion and exhaust resources needed by other users. The defensive goal is not to guess which compressed files are malicious. It is to put a hard boundary around the work the application is willing to perform.

Cybersecurity Secure Coding

Cybersecurity / 10 Sep 2026 / 12 min read

Bind OAuth Callbacks to the Login That Started Them

An OAuth callback can look valid even when it belongs to the wrong browser interaction. The authorization server may have issued a real code, the redirect URI may be correct, and the code exchange may succeed. Yet if the client cannot tell whether this browser actually started that authorization flow, it can attach the wrong external identity or authorization to the current session. This is a form of cross-site request forgery at the OAuth callback. In a login flow, one possible consequence is login CSRF: a victim can end up signed into the client as an account associated with someone else. The details vary by application, but the defensive question stays the same: does this callback belong to a login transaction that this user agent started?

Cybersecurity OAuth