Skip to content
websitecontrole.nl
Advice

Tuning the security of a headless or framework site

When your site runs on a framework or a separate frontend that pulls content from a headless CMS, the headers are set on the frontend host, not in the CMS. This is the correction that matters most: generic advice sends a headless owner to the wrong place.

Response headers (CSP, HSTS, X-Frame-Options, cookies)

These belong on the frontend host or in your framework's header config, not in the CMS. On a static host you set them in that host's header config (a _headers file on Netlify or Cloudflare Pages, or headers in vercel.json, say). On a framework it can also live in the framework itself: Next.js has a headers() function, Nuxt has route rules, Astro has middleware.

In the page (a hash on a script, trackers after consent)

Repairs in the page live in the frontend components that render the tags: a hash on an external script, or trackers that load only after consent. Load analytics and advertising through your consent platform or a tag manager that waits for the answer.

The connection (HTTPS and the certificate)

Forcing HTTPS and the certificate are your host or CDN. Make sure http redirects to https and the certificate is valid and not expired. Most hosts and CDNs do this with a toggle or a free Let's Encrypt certificate.

Read more

DNS records (SPF, DMARC, DNSSEC, IPv6)

These sit apart from your site: they are records at your domain. Set them with your DNS provider or domain registrar, not in your CMS or on your host. SPF and DMARC govern who may send mail as your domain, DNSSEC signs your DNS, and IPv6 is the one where the host has to offer an AAAA record and a connection before you can add it.

Go deeper

Advice for another platform