File Security

Cybersecurity / 17 Sep 2026 / 5 min read

openat2 Makes Path-Resolution Policy Part of the Open

openat2 Makes Path-Resolution Policy Part of the Open A service receives a relative pathname and intends to open only objects below a directory it already trusts. A lexical check can reject obvious .. components, yet the filesystem namespace may contain symbolic links, mount points, or concurrent renames that change the path walk after that check. The security decision and the file open then describe two different moments. Linux openat2() provides a narrower boundary. Its resolve flags constrain the kernel’s path-resolution operation that produces the file descriptor. The mechanism does not make arbitrary path handling safe, but it can move several confinement rules from preflight string logic into the lookup that actually selects the object.

Cybersecurity Linux

Cybersecurity / 12 Sep 2026 / 7 min read

Archive Extraction Is a Filesystem Security Boundary

Archive Extraction Is a Filesystem Security Boundary An archive extractor can receive a destination directory, join each stored name beneath it, and still write somewhere else. The gap appears when archive metadata is treated as harmless naming information even though extraction ultimately asks a filesystem to resolve paths, links, and object types with its own semantics. The familiar ../ traversal is only the most visible form of the problem. Absolute paths, symbolic links, hard links, platform-specific path syntax, pre-existing filesystem objects, and replacement races can all affect where a write lands. A robust design therefore cannot reduce extraction safety to a string check performed once before files are created.

Cybersecurity File 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 / 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

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