Security

Markdown is rendered as untrusted input in src/markdown.ts: raw HTML is escaped rather than passed through, link and image destinations must be http, https or mailto, and text is escaped into every attribute. An editor is authenticated, so this is the second line of defence, not the first. The trade is that an author cannot embed raw HTML or an iframe. When you want that, the answer is a content field your frontend renders deliberately, not a hole here.

The same renderer is its own entry, barakopress/markdown, for code that runs in the browser, such as an editor previewing a post. The only package it reaches is marked, where the main entry also pulls in next/cache, next/server and node:crypto.

import { renderMarkdown } from "barakopress/markdown";

renderMarkdown(source);                                     // what the site renders
renderMarkdown(source, { headingIds: false, newTab: true }); // no ids, links open a new tab

Both options change only the markup around what is already sanitised. headingIds defaults to true and newTab to false, which is the site's output.

Two behaviours that were measured, not assumed

revalidateTag needs { expire: 0 }, not a named profile. Next 16 made the second argument mandatory. Passing "max" left the prerendered sitemap stale indefinitely.

Cache warming after a purge does nothing, so there is none. An earlier version fetched the main pages after purging, on the theory that Next serves one stale response after a purge and the server should absorb it rather than a reader. Measured against a CMS that logged every read, those fetches caused zero reads: { expire: 0 } already makes the next request a blocking miss. It cost three requests per delivery and tripled what an attacker got from one captured signature, for nothing.