{"id":3983,"date":"2026-07-30T03:42:38","date_gmt":"2026-07-30T03:42:38","guid":{"rendered":"https:\/\/tucumandevelopers.com\/index.php\/2026\/07\/30\/security-notes-for-serving-static-files-with-staypresent\/"},"modified":"2026-07-30T03:42:38","modified_gmt":"2026-07-30T03:42:38","slug":"security-notes-for-serving-static-files-with-staypresent","status":"publish","type":"post","link":"https:\/\/tucumandevelopers.com\/index.php\/2026\/07\/30\/security-notes-for-serving-static-files-with-staypresent\/","title":{"rendered":"Security Notes for Serving Static Files with StayPresent"},"content":{"rendered":"
\n
<\/div>\n

<\/a> Why This Is Intentional <\/h2>\n

This isn’t an oversight \u2014 it’s what makes web.html()<\/code>\/web.markdown()<\/code> usable with zero configuration for the overwhelming majority of legitimate cases (a template directory containing only the page and its assets). Requiring an explicit allowlist of every servable file for every deployment would defeat the “read fresh from disk” simplicity that makes these two functions useful in the first place. StayPresent’s own documentation notes that an opt-in allowlist restricting exposure to only referenced<\/em> files is being considered for a future release \u2014 but as things stand, the responsibility for directory contents is on you.<\/p>\n

<\/a> Path Traversal Protection <\/h2>\n

What StayPresent does<\/em> protect against automatically is path traversal \u2014 a request trying to escape the target directory entirely, via ..\/<\/code> sequences, absolute paths, or similar tricks. Static asset lookups use send_from_directory<\/code> internally, which refuses to serve any path that would resolve outside the intended directory. So while every file inside<\/em> templates\/<\/code> is reachable, nothing outside<\/em> it is, regardless of how a request tries to reference it.<\/p>\n

<\/a> The One-Time Directory Warning <\/h2>\n

StayPresent logs a one-time WARNING<\/code>-level message through the \"staypresent\"<\/code> logger the first time html()<\/code> or markdown()<\/code> exposes a given directory as a static-asset fallback \u2014 specifically as a reminder that this exposure is directory-wide: <\/p>\n

\n
import<\/span> logging<\/span> logging<\/span>.<\/span>getLogger<\/span>(<\/span>\"<\/span>staypresent<\/span>\"<\/span>).<\/span>setLevel<\/span>(<\/span>logging<\/span>.<\/span>WARNING<\/span>)<\/span> # ... elsewhere ... <\/span>staypresent<\/span>.<\/span>web<\/span>.<\/span>html<\/span>(<\/span>\"<\/span>templates\/index.html<\/span>\"<\/span>)<\/span> # WARNING logged once: directory 'templates\/' is now servable as static assets <\/span><\/code><\/pre>\n
\n<\/p><\/div>\n<\/p><\/div>\n
This warning fires once per directory per process, not once per request \u2014 it’s meant to catch your attention during development or the first deploy, not spam your logs continuously.<\/p>\n
  <\/a> Markdown-Specific Protections: Escaping <\/h2>\n
Beyond directory exposure, web.markdown()<\/code> has its own layer of protection specific to rendering user-authored (or at least file-authored) content into HTML. Plain text \u2014 and every recognized Markdown construct \u2014 is HTML-escaped before rendering, applied exactly once per character, including inside link\/image URLs and titles. A .md<\/code> file containing literal <script><\/code> tags, or stray <<\/code>, ><\/code>, &<\/code> characters, cannot inject markup into the rendered page. Only a fixed list of recognized block-level raw-HTML tags (the kind used for centered logo\/badge headers) is ever passed through unescaped \u2014 arbitrary inline HTML is not.<\/p>\n
  <\/a> Markdown-Specific Protections: URL Scheme Filtering <\/h2>\n
Escaping alone doesn’t stop an executable<\/em> destination \u2014 a link that’s syntactically valid Markdown but points somewhere dangerous. web.markdown()<\/code> checks link\/image URLs against a scheme blocklist independently of escaping:<\/p>\n