The zero-JavaScript static site is a defensible choice

Thu, 13 Aug 2026 00:00:00 +0000

A static site does not need JavaScript to be defensible; the absence of a <script> tag can itself be the point. This essay argues the engineering case for shipping a site whose script lanes are closed by policy, then explains how to verify the policy at the public edge. The header below is the repository’s intended configuration, not a fresh observation of production.

The argument has three parts: the threat surface you delete, the contract that makes deletion observable, and the cases where deleting the layer is the wrong call.

Assumes the article’s complete enforcing CSP with no more-specific script allowance. Report-Only does not block. The three checks shown are required evidence, not completed tests.

The threat surface you delete by not having a script lane

A page that executes no own or third-party script removes the client-side script dependencies that would otherwise need patching and review. An effective no-script CSP blocks injected script execution in conforming browsers, but HTML injection can still change text, links, and page structure. Trackers can also use images, navigation, or server logs without JavaScript. This site separately avoids third-party browser dependencies; that is a broader requirement than removing script tags. Browser-bundle dependency drift disappears when there is no bundle, while build-tool and server dependencies remain. Each of these is a bounded, nameable surface — the small-systems property of choosing boundaries you can articulate.

None of this claims the site is “secure”. It claims the attack surface is narrower and, crucially, easier to reason about because it is enumerated by construction rather than by audit.

The header that makes the boundary enforceable

A taste is not a policy. The difference here is that the server delivers a policy that the browser enforces. The example Caddy configuration in this repository specifies:

content-security-policy: default-src 'self'; base-uri 'self'; form-action 'none'; frame-ancestors 'none'; object-src 'none'; script-src 'none'; style-src 'self'; img-src 'self' data:

The script-src 'none' directive is the enforceable part. With this complete policy and no more specific script allowance, a conforming browser refuses page scripts, inline handlers, and JavaScript URLs. A Content-Security-Policy-Report-Only header would only report violations, not block them. Later additions of script-src-elem or script-src-attr need review because they can override the fallback for their respective script categories.

The build verifier checks generated artifacts for executable scripts, handlers, and URLs. It cannot prove that a reverse proxy serves the intended CSP. Fetch representative HTML, error pages, and redirect destinations separately; inspect the actual enforcing header and test browser behavior. Source inspection, response inspection, and browser execution are three distinct checks.

What the static structure buys after the removal

With no scripting, the content model reverts to something closer to published documents. Caching operates on HTTP representations, not on a page’s later DOM mutations. Static output makes those representations easy to inspect and version; an ETag and freshness policy still depend on server configuration. Reading the served HTML in a terminal, using view-source, or indexing the tree is straightforward because the artifact is ordinary files on disk. The trade the site accepts is deliberate: no script-managed state, no client-side rendering, and no feedback that needs a JavaScript view model. Native links, keyboard navigation, CSS behavior, and elements such as details can still provide interaction. For a documentation and operations site that is the correct exchange, and it is worth writing down.

When the zero-JS claim is the wrong call

The boundary is a feature, not a badge of purity. A site that genuinely needs client-side interactivity — a realtime dashboard, a document editor, a payment flow — should not contort itself into serving static HTML and then bolting on a workaround. The wrong application of this decision is to shave a product to fit the constraint. The right application is to recognize that content that is read, searched, and archived profits from being a document, and to reserve scripting for where a document is insufficient.

For this property, the served header is useful evidence for the response sampled. It does not prove universal browser support or that every route has the same policy. Keep the underlying content safe to render, protect publishing access, and maintain the generator and server. The boundary is defensible precisely when its limits are explicit.

Sources