Security in Eleventy

A traditional CMS exposes a database, an admin login, and a stack of plugins that all run on every request — each one a potential entry point for SQL injection, remote code execution, or privilege escalation. An Eleventy site has none of that at runtime. Visitors receive pre-built files from a CDN, so there is no live application server to compromise.

Any value you render with {{ }} in a Nunjucks template is HTML-escaped, so a string like <script> is shown as text instead of executed. The escape hatch is the safe filter — it outputs raw HTML, so only ever pass it content you trust or have sanitized.

{# userBio comes from a CMS or user-generated content, untrusted #}

{# ✅ Safe: Nunjucks HTML-escapes automatically #}
<p>{{ userBio }}</p>

{# ❌ Dangerous: `safe` outputs raw HTML, bypassing escaping #}
<p>{{ userBio | safe }}</p>

When you genuinely need to render user-supplied HTML (a rich-text bio, Markdown from an untrusted source), sanitize it first. Add a filter in your config backed by a library like sanitize-html, then pipe through it before safe.

// .eleventy.js
const sanitizeHtml = require("sanitize-html");

module.exports = function (eleventyConfig) {
  eleventyConfig.addFilter("sanitize", (html) => sanitizeHtml(html));
};

Now <p>{{ userBio | sanitize | safe }}</p> renders the HTML raw, but stripped of scripts and event handlers first.

You can read process.env in your config, in global data files, and in JavaScript templates — all of which run only during the build. None of it ships to visitors unless you explicitly print it into a page. The starter already relies on this pattern: it reads ELEVENTY_ENV (set to PROD on Netlify builds) to toggle minification. Use dotenv for local values and keep your .env file out of git.

# .env  (add to .gitignore, never commit secrets)
API_TOKEN=secret_xxxxx          # used at build time to fetch data
ANALYTICS_ID=G-XXXXXXX          # safe to print into the page

A global data file in src/_data/ — alongside the kit's own client.js — can use a secret to fetch from an API while only the returned data — never the token — ends up in your pages:

// src/_data/products.js , runs at build time only
module.exports = async function () {
  const res = await fetch("https://api.example.com/products", {
    headers: { Authorization: `Bearer ${process.env.API_TOKEN}` },
  });
  // Only this returned data is rendered, the token never reaches the page
  return res.json();
};

Because a finished Eleventy site is just files, dynamic work like contact forms, payments, or search is delegated to specialized providers — Netlify Forms, Formspree, Stripe, and the like. They handle spam filtering, validation, and CSRF on their own hardened infrastructure, keeping sensitive operations off your public site entirely.

<!-- A Netlify form, submissions are processed by Netlify, not by you -->
<form name="contact" method="POST" data-netlify="true">
  <input type="hidden" name="form-name" value="contact" />
  <label>Email <input type="email" name="email" required /></label>
  <label>Message <textarea name="message" required></textarea></label>
  <button type="submit">Send</button>
</form>

The starter bundles Decap CMS so a client can edit blog posts. It looks like an admin panel, but it is just static HTML and JavaScript: it has no server, no database, and no password store of its own. Logins are delegated to DecapBridge, and approved edits are committed straight to your Git repository — which then triggers a fresh Netlify build. There is nothing on your public site to brute-force.

Since Eleventy ships only files, response headers are configured where you deploy. This starter deploys to Netlify, which reads a _headers file from your output folder (drop it in src/ so it copies into public/, next to the kit's existing _redirects).

# src/_headers  (copied into public/, served by Netlify)
/*
  Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
  X-Content-Type-Options: nosniff
  Referrer-Policy: strict-origin-when-cross-origin
  X-Frame-Options: DENY
  Permissions-Policy: geolocation=(), microphone=(), camera=()

Prefer config over a copied file? The starter already ships a netlify.toml at the repo root — add a headers block to it:

# netlify.toml
[[headers]]
  for = "/*"
  [headers.values]
    X-Content-Type-Options = "nosniff"
    Referrer-Policy = "strict-origin-when-cross-origin"
    X-Frame-Options = "DENY"

Eleventy assembles data from many sources at build time. Validating anything from an external source means a bad upstream response fails the build instead of shipping broken or unsafe markup. A schema library like zod works well inside a data file:

// src/_data/posts.js , validate external data before it's rendered
const { z } = require("zod");

const PostSchema = z.array(
  z.object({
    title: z.string().min(1),
    slug: z.string().regex(/^[a-z0-9-]+$/),
    body: z.string(),
  })
);

module.exports = async function () {
  const res = await fetch("https://cms.example.com/posts");
  // Throws and fails the build if the shape is wrong
  return PostSchema.parse(await res.json());
};