Skip to content
websitecontrole.nl
Advice

Tuning the security of a self-hosted CMS

When you run a CMS or webshop on your own server, you decide the headers and the shape of the page. Where a repair goes depends on what is wrong. Below, per kind of fix, where it belongs, whatever CMS you run.

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

Set these in one place for the whole site. Two routes: on the web server (the server block on nginx, or a .htaccess on Apache), or in your CMS through an extension or module that centralises security headers. Many CMSes have one; pick one that is actively maintained. Start a Content-Security-Policy in report-only and only enforce it once nothing breaks.

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

Repairs in the page go in your template or theme layer (Twig, Blade, Antlers, or your CMS's theme, say): 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