Input Validation

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

Constrain Server-Side URL Fetches

Applications often fetch remote resources on behalf of users. Image importers, webhook testers, document converters, link preview services, feed readers, and URL-based upload features all need outbound network access. That capability becomes a security boundary as soon as an untrusted party can influence the destination. A server can usually reach systems that an internet client cannot. It may have access to loopback services, private subnets, cloud metadata endpoints, internal administration panels, service discovery systems, or trusted network peers. A server-side request forgery flaw, commonly called SSRF, turns the application’s network position into an attack primitive.

Cybersecurity SSRF

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 / 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 Application Security

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 / 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 XML

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 / 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 / 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 / 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 / 10 min read

Validate DNS Results Before Connecting to Untrusted Hostnames

A server that accepts a hostname from a user can make a careful security decision and still connect somewhere it never intended. The common mistake is validating the hostname first, then assuming that the later network connection will reach the same kind of destination. Hostnames are names, not network locations. DNS turns a hostname into one or more IP addresses, and those answers can change. If your security rule says “public destinations only,” checking the text of the hostname is not enough. The connection must also be constrained to an address that satisfies that rule.

Cybersecurity Network Security

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

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 / 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 / 9 min read

Design User Identifiers to Resist Visual Spoofing

Two account identifiers can be different to software while looking almost identical to a person. That gap matters anywhere people use a displayed identifier to decide whom they are trusting: administrator consoles, collaboration tools, package registries, marketplaces, support systems, or internal approval workflows. If an application treats visual appearance as irrelevant, an attacker may be able to register an identifier that resembles a trusted account closely enough to mislead another user. The database still sees two distinct strings. The human may not.

Cybersecurity Secure Design

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