Secure Coding

Cybersecurity / 12 Sep 2026 / 9 min read

Reject Native Object Deserialization from Untrusted Inputs

Native object serialization can be convenient inside a trusted process boundary. A runtime can preserve object types, references, inheritance details, and other implementation state with very little application code. That convenience becomes dangerous when serialized bytes cross a trust boundary. Many native object formats do more than decode passive data. Their decoders may resolve classes, allocate arbitrary object graphs, invoke constructors or callbacks, restore proxies, or trigger other runtime behavior. An attacker who controls the input can then influence operations that were never intended to be part of parsing.

Cybersecurity Secure Coding

Cybersecurity / 12 Sep 2026 / 8 min read

Reject Ambiguous HTTP Message Framing

Modern web requests often cross several HTTP-speaking components before reaching application code. A request may pass through a CDN, load balancer, reverse proxy, API gateway, service mesh, and application server. Each component must agree on exactly where one request ends and the next begins. If two components interpret message boundaries differently, bytes that one component treats as part of a request can become a second request for another component. This parser disagreement is the foundation of HTTP request smuggling.

Cybersecurity HTTP Security

Cybersecurity / 12 Sep 2026 / 7 min read

Prototype Pollution Turns Object Shape Into Shared State

A configuration object arrives with ordinary JSON fields, passes schema checks for the values the application expects, and is merged into defaults. Later, code in another part of the process reads a property that was never present on its own object. The value still exists. It came through the prototype chain. That separation between the write and its eventual effect is what makes prototype pollution unusually awkward to reason about. The vulnerable operation can look like routine object plumbing: recursive merge logic, path-based assignment, query parsing, or a helper that copies attacker-controlled keys. The security consequence appears only when another component treats inherited state as if it were local, trusted configuration.

Cybersecurity Application Security

Cybersecurity / 12 Sep 2026 / 6 min read

Native Object Deserialization Expands the Trusted Computing Surface

A serialized object can look like ordinary application data at the edge of a system and behave very differently once it reaches a native object decoder. The distinction matters because some serialization mechanisms do more than parse fields. They reconstruct types, restore object graphs, resolve references, and invoke behavior associated with object creation or restoration. That capability is convenient inside a trusted boundary. Across an untrusted boundary, it can make the application’s installed code part of the input language.

Cybersecurity Secure Coding

Cybersecurity / 12 Sep 2026 / 10 min read

Make Password Reset Tokens Single Use

Password recovery is an authentication path with unusual power. A reset link can let its holder replace an account password without presenting the current password, so the token inside that link must be treated as a short-lived credential. A strong token is not enough by itself. If the same token remains valid after a successful reset, a copied link can be replayed. If two requests can validate the same token before either request marks it used, both may pass. If a database stores raw reset tokens, a database disclosure can turn pending recovery records into immediate account access.

Cybersecurity Authentication

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 Authentication Security

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 Secure Coding

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 Secure Coding

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 Security Logging

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 TLS

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 Secure Coding

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 Web Security

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 Secure Coding

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 Secure Coding

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 / 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 / 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 / 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 / 09 Sep 2026 / 11 min read

Treat Spreadsheet Exports as Active Content

A CSV export can look harmless because the application is only writing text. The risk appears later, when a spreadsheet program opens that text and decides that a cell is a formula rather than ordinary data. If an attacker can control a field that appears in an export, a value intended to be a name, note, ticket title, or other text may be interpreted by the spreadsheet application as active spreadsheet content. The consequence depends on the spreadsheet software and its configuration, but it can include misleading calculated values, unexpected links or external interactions, and other behavior the exporting application never intended to authorize.

Cybersecurity Secure Coding