Secure Coding

Cybersecurity / 09 Sep 2026 / 9 min read

Treat Client-Side Authorization State as Untrusted Input

Applications often send useful state to a client: a user role for rendering navigation, an owner identifier for displaying a record, or a flag that controls whether a button appears. The security problem begins when the server later accepts that client-supplied state as proof that an action is allowed. A client is outside the server’s trust boundary. A browser, mobile application, API consumer, or desktop client can send requests that differ from the interface the developer intended. If changing a client-controlled field can change an authorization result, a user may gain authority that the server never granted.

Cybersecurity Access Control

Cybersecurity / 09 Sep 2026 / 10 min read

Normalize Once Before Security Validation

A security check can inspect the right field and still make the wrong decision if another component interprets that field differently later. Consider an application that accepts a path-like identifier. One layer rejects values containing a forbidden segment. A later layer decodes or normalizes the value before using it. If those two layers do not agree on what the input means, the application may approve one representation and act on another.

Cybersecurity Secure Coding

Cybersecurity / 09 Sep 2026 / 10 min read

Make Sensitive Requests Replay-Resistant

A server can correctly prove that a request came from a trusted client and still process it more times than intended. If an authenticated request says “approve this payout” or “change this recovery address,” accepting the same valid request twice can create a security problem even though neither copy was forged. This is a replay problem. A replay happens when a previously valid message is presented again and the receiver cannot tell that its authority has already been used, or that the message is too old to trust.

Cybersecurity Authentication

Cybersecurity / 09 Sep 2026 / 11 min read

Limit Decompression Before Processing Untrusted Archives

An upload limit can look like a complete resource limit until the application accepts compressed input. A small archive may expand into far more data than its uploaded size suggests, contain an excessive number of entries, or require enough decompression work to tie up workers. If the service trusts the compressed size, an attacker may be able to exhaust disk, memory, CPU time, or processing capacity without sending a large request.

Cybersecurity Secure Coding

Cybersecurity / 09 Sep 2026 / 10 min read

Build Security-Sensitive URLs from Trusted Origins

A password-reset endpoint often needs to send an absolute URL such as https://accounts.example/reset?.... A tempting implementation is to take the hostname from the incoming HTTP request and prepend it to the reset path. That shortcut creates a trust problem. The request’s authority information, commonly exposed to application code through Host, :authority, or proxy-derived host fields, describes where the client says the request is addressed. It is not proof that the value is an approved public origin for links containing sensitive tokens.

Cybersecurity Secure Coding

Cybersecurity / 08 Sep 2026 / 12 min read

Validate Uploaded Files by What You Will Do with Them

A file upload endpoint often starts with a simple rule: accept .jpg images, .pdf documents, or another small set of formats. The mistake is assuming that a filename or an HTTP Content-Type value proves what the uploaded bytes really are. Both values come from the client. They are useful hints, but they are not a security boundary. If an application accepts a file because its name ends in .jpg and later sends those bytes to an image decoder, document converter, browser, or other parser, the component consuming the file becomes the place where the real security consequences appear.

Cybersecurity Secure Coding

Cybersecurity / 08 Sep 2026 / 11 min read

Prevent Log Forging with Structured Events

Security logs are useful only if responders can trust what an event means. That trust can fail when an application builds log records by joining trusted text with untrusted values. A username, request parameter, filename, or external error message may contain line breaks, delimiters, terminal control characters, or text that resembles the application’s own log format. If that value is inserted directly into a text record, it can make one event appear to be several events, hide where fields begin and end, or mislead a person reading the log.

Cybersecurity Security Logging

Cybersecurity / 08 Sep 2026 / 9 min read

Keep Untrusted Data Out of Object Deserializers

A serialized object can look like ordinary input: bytes arrive from a request, queue, cache, file, or database and the application turns them back into an object. The important difference is that some object deserializers do more than decode values. They can choose application types, reconstruct object graphs, and invoke type-specific behavior while reconstruction is happening. That makes object deserialization a security boundary. If an attacker can influence the serialized bytes, treating those bytes as instructions for rebuilding application objects can lead to unexpected state, denial of service, or, with some formats and available types, code execution.

Cybersecurity Secure Coding

Cybersecurity / 08 Sep 2026 / 10 min read

Confine Archive Extraction to a Trusted Directory

An application that accepts ZIP, TAR, or similar archives may appear to be handling one uploaded file. During extraction, however, the archive can ask the application to create many filesystem objects with names chosen by whoever created the archive. If those names are treated as trusted paths, extraction can write outside the directory the application intended to use. The consequence can be more serious than a misplaced file. Depending on the process permissions and surrounding system, an unintended write might replace application data, alter configuration, or place content where another component will later consume it.

Cybersecurity Secure Coding

Cybersecurity / 08 Sep 2026 / 8 min read

Compare Security Secrets Without Leaking Match Length

Applications compare secret values in places that look deceptively simple: message authentication codes, signed-request tags, API tokens, and other authentication material. A normal string or byte equality operator may return as soon as it finds a mismatch. When the compared value is secret, that data-dependent work can create a timing signal about how much of a guess matched. This does not mean every ordinary string comparison is remotely exploitable. Network noise, runtime behaviour, compiler optimisations, rate limits, and the surrounding protocol all affect what an attacker can measure. The defensive lesson is narrower: when equality itself protects a secret or cryptographic authenticator, do not make its comparison time depend on the matching prefix if your platform already provides a hardened comparison primitive.

Cybersecurity Secure Coding

Cybersecurity / 08 Sep 2026 / 10 min read

Compare Secret Values Without Data-Dependent Early Exit

Applications compare secret-derived values in many places: webhook message authentication codes, API tokens, password-reset tokens, signed request authenticators, and other proofs that a caller knows a secret. A normal string or byte comparison may stop as soon as it finds a difference. That is efficient for ordinary data, but it can be the wrong behavior at a security boundary. If the amount of comparison work depends on where two secret values first differ, an observer may be able to learn something from repeated timing measurements. Whether that signal is practically exploitable depends on the surrounding system, noise, protocol, implementation, and attacker access. The defensive decision is still straightforward: when equality of a secret or secret-derived authenticator controls access, use the platform’s dedicated constant-time comparison primitive rather than writing the comparison yourself.

Cybersecurity Secure Coding

Cybersecurity / 08 Sep 2026 / 8 min read

Canonicalize Resource Identifiers Before Authorization

Access control becomes unreliable when the application authorizes one representation of a resource but later operates on another. A file may be reachable through aliases, an object may have both a public name and an internal ID, or a path may have several textual forms that resolve to the same target. If different parts of the request pipeline disagree about identity, an authorization check can answer the wrong question. The defensive rule is to establish a canonical resource identity before making the security decision. Canonical means the single representation that the application treats as authoritative for identifying that resource. Resolve untrusted names or aliases to that identity, authorize the identity, and make the protected operation use the same resolved object.

Cybersecurity Access Control

Cybersecurity / 08 Sep 2026 / 8 min read

Build Security Links from Trusted Origins

Applications often need to send absolute links in email: password-reset links, email-verification links, invitation links, and similar security-sensitive URLs. A convenient implementation takes the hostname from the incoming HTTP request and combines it with a generated token. That convenience can cross a trust boundary. Request host information is input, and deployments may also receive forwarded host information from proxies. If an attacker can influence the value used to build a security link, the application can generate a valid secret token but place it inside a URL for the wrong origin. A user who follows that URL may disclose the token to a host the application does not trust.

Cybersecurity Secure Coding

Cybersecurity / 08 Sep 2026 / 10 min read

Avoid Check-Then-Use Races in File Operations

A program often checks a file before using it. It may confirm that a path is inside an allowed directory, that the target is not a symbolic link, that the file belongs to an expected user, or that it does not already exist. The code then opens, replaces, deletes, or executes the file. The security problem is the gap between those two operations. If another actor can change the relevant filesystem state after the check but before the use, the program may validate one object and operate on another. This is a time-of-check to time-of-use race, often shortened to TOCTOU.

Cybersecurity Secure Coding

Cybersecurity / 07 Sep 2026 / 8 min read

Verify the Entire Password Without Truncation

A password field may accept 100 characters while the authentication system verifies only the first 72, 64, or 20. The interface appears to accept the whole password, but the security decision does not. That mismatch is password truncation: silently discarding part of a password before storing or verifying it. Truncation can make two visibly different passwords authenticate as the same credential. It can also create confusing migration bugs when one component preserves the full password and another shortens it.

Cybersecurity Authentication

Cybersecurity / 07 Sep 2026 / 10 min read

Treat File Uploads as Untrusted Content

A file-upload feature can appear simple: accept bytes, save them, and let another user download them later. The security problem is that the uploaded file crosses several trust boundaries. Its name, declared type, contents, and eventual delivery behavior are all influenced by the uploader. If the application treats any of those properties as trustworthy, an ordinary upload can become an unintended way to consume excessive resources, overwrite data, feed dangerous content into a parser, or make a browser handle attacker-controlled bytes in a more powerful context than intended.

Cybersecurity Secure Coding

Cybersecurity / 07 Sep 2026 / 11 min read

Keep Archive Extraction Inside Its Destination

Extracting an archive looks like a file-copying task: read each entry, join its name to a destination directory, and write the bytes. The security problem is that an archive entry name is input chosen by whoever created the archive. If that name can influence the output path without a containment check, extraction can write outside the directory the application intended to grant. The consequence is broader than a misplaced file. Depending on the process’s permissions, an escaped write may replace application data, configuration, generated assets, or another file that the extractor can modify.

Cybersecurity Secure Coding

Cybersecurity / 07 Sep 2026 / 9 min read

Compare Secret Values Without Timing Leaks

Applications compare security-sensitive values constantly: message authentication codes, webhook signatures, API tokens, recovery codes, and other secret authenticators. A normal string or byte comparison may stop as soon as it finds a mismatch. That is efficient, but when the compared value is secret, the amount of work can depend on how much of the candidate matched. If an attacker can obtain useful timing measurements over many attempts, data-dependent comparison time can become an information leak. The practical defense is not to write a clever comparison loop. Use a well-reviewed constant-time comparison primitive provided by the language, cryptographic library, or platform for secret values of the expected form.

Cybersecurity Secure Coding

Cybersecurity / 06 Sep 2026 / 11 min read

Validate File Uploads Before You Trust Them

A file upload endpoint accepts more than bytes. It also receives a filename, a declared content type, a size, and often assumptions about what the application will do with the file later. The security problem begins when those claims are treated as proof. A user can rename a file. A client can send an arbitrary Content-Type value. A file can satisfy one superficial check while still being unsuitable for the parser, storage location, or download behavior that follows. If the application accepts the wrong file, the consequence may be unsafe parsing, unexpected active content, storage abuse, or a file being served in a context the application never intended.

Cybersecurity Secure Coding

Cybersecurity / 06 Sep 2026 / 10 min read

Turn Security Requirements Into Invariants

Security requirements often begin as broad statements: “users must not read other users’ records,” “disabled accounts must not create new sessions,” or “a refund must require approval.” These statements describe the desired outcome, but they do not yet tell a developer where the rule must hold or what code should make it true. That gap matters. A rule enforced in one screen can be bypassed by another API path. A check performed before a state change can become stale before the write completes. A background worker may operate under different assumptions from the request that queued its job. The result is not necessarily a missing security feature; it is often a security property that was never made precise enough to enforce consistently.

Cybersecurity Threat Modeling

Cybersecurity / 06 Sep 2026 / 12 min read

Separate Public Errors from Diagnostic Details

An application fails while processing a request. The easiest implementation is often to return the exception message to the caller. That feels helpful during development because the response explains exactly what went wrong. In production, the same detail can expose information that the caller did not previously know: filesystem paths, database structure, dependency names, internal service addresses, object identifiers, configuration values, or fragments of sensitive input. A stack trace can reveal even more about how the application is assembled.

Cybersecurity Secure Coding

Cybersecurity / 06 Sep 2026 / 10 min read

Normalize Before Making Security Decisions

A security check can inspect the right data and still reach the wrong decision if another component changes that data afterward. A path may be validated before path resolution removes .. segments. A percent-encoded value may pass a character check and then gain different characters when a later layer decodes it. Two names that look different to one component may be treated as equivalent by another. The consequence is a representation mismatch: the security decision is made about one form of a value, while the sensitive operation uses another. An attacker does not need to defeat the policy itself if they can make the validator and the consumer disagree about what the input means.

Cybersecurity Secure Coding

Cybersecurity / 06 Sep 2026 / 10 min read

Consume One-Time Tokens Atomically

A password-reset link may be labelled “single use” while still being usable twice. The problem is often not token randomness or expiration. It is a race between two requests that both verify the token before either request marks it as used. That matters because temporary tokens frequently authorize sensitive actions: resetting a password, verifying an email address, accepting an invitation, or completing account recovery. If the application promises one-time use, concurrent requests should not be able to turn that promise into two successful authorizations.

Cybersecurity Authentication

Cybersecurity / 06 Sep 2026 / 9 min read

Compare Secret Values with Constant-Time Functions

A verifier often ends with a simple question: does a value derived from this request match the value the system expects? That question appears when checking message authentication codes, signed-request authenticators, reset-token digests, and other security-sensitive values. Using an ordinary string or byte comparison can introduce a subtle problem. Some comparison routines stop as soon as they find the first difference. Their work can therefore depend on how much of the input matches. If an attacker can make many measurements under sufficiently stable conditions, that timing difference may reveal information about a secret-dependent value.

Cybersecurity Secure Coding