← Insights

Security

A secure filesystem as the foundation of a CMS

Flat-file does not mean naïve file operations. It is a deliberate data model whose security starts long before an admin form.
Documents passing through transparent validation gates

A path is part of the input

The most dangerous filesystem bugs often begin innocently: by joining a base directory with a name submitted through a form. FlatFile CMS resolves paths against known roots and rejects every attempt to escape their boundaries.

This applies to pages, configuration, media and renderers. Block packages are developer-owned code — the panel can manage their data, but never their PHP files.

Writes must be atomic

Updating YAML must not leave half a document behind if the process is interrupted. New content first goes to a private temporary file. Only after a complete write and successful validation is it safely moved into place.

The same pattern supports write locks and conflict control. An administrator receives an error while the previous content remains valid.

Media is no exception

A filename extension does not determine its actual type. The media layer verifies MIME, file-size limits and image dimensions. SVG files are sanitized and raster variants are generated within controlled memory boundaries.

Public URLs contain fingerprints, enabling long-lived caching without serving stale assets.

Audit closes the loop

Administrative operations record who changed which resource and when. The log does not replace access control, but it explains system history without relying on filesystem timestamps.

Key takeaway

Flat-file simplicity is an advantage only when every write operation has clearly defined boundaries and failure behavior.

Visual study

Every document follows a controlled path

Glowing documents passing through security gates
Validation completes before the change is published in its destination directory.