What security headers can and cannot do
Security headers are instructions sent with a website’s responses. A browser reads them and changes how it handles the page. Depending on the header, it might refuse to load an unexpected script, prevent a page from being displayed inside another site’s frame, or send less information when a visitor follows a link.
Headers are useful, but they are not a substitute for updating your software, using strong account protection, or fixing unsafe code. A restrictive header can also break a working page if it blocks a font, form, video, or script the page needs. For a small website, the goal is not to switch on every setting at once. It is to understand what the site uses, add a few appropriate protections, and check the result.
Start with the headers that are easiest to assess
X-Content-Type-Options: nosniff tells browsers not to guess a different file type when a resource is served with a declared content type. It is a reasonable early addition, but it may reveal files that your server labels incorrectly. If a stylesheet or script stops loading, check its Content-Type response rather than removing the header without investigation.
Referrer-Policy controls how much of the current page’s address is sent when a visitor follows a link or loads an external resource. The value strict-origin-when-cross-origin is a practical starting point for many sites: it limits what is shared across sites while retaining more detail for navigation within the same site. If your pages put sensitive information in URLs, review that practice too; a header should not be the only safeguard.
Framing rules help prevent another site from placing your pages inside an iframe. For a site that does not need to be embedded elsewhere, consider Content-Security-Policy: frame-ancestors 'self'. If you need to support older browsers, X-Frame-Options: SAMEORIGIN can provide an additional framing rule. Before adding either, check whether a partner site or service legitimately embeds your pages.
Treat HTTPS and Content Security Policy as deliberate projects
Strict-Transport-Security, often called HSTS, tells browsers to use HTTPS for future visits to your site. First confirm that HTTPS works throughout the site and that HTTP requests redirect correctly. Begin with a modest max-age so you can correct a configuration mistake sooner. Do not add includeSubDomains unless every relevant subdomain is ready for HTTPS. Preloading is a further commitment and is not a necessary first step for most small sites.
Content Security Policy, or CSP, can limit where a page loads scripts, styles, images, and other resources from. It can be valuable, especially against some forms of injected content, but it requires an inventory of what the site actually loads. A ready-made policy copied from another site may block your analytics, contact form, embedded map, or content-management interface. It may also be so broad that it offers little protection.
Start a CSP project by listing the services and assets each page needs. Consider testing a policy with Content-Security-Policy-Report-Only before enforcing it, while remembering that reports need somewhere to be received and reviewed. Tighten the policy in stages, test important page types, and avoid permitting all sources simply to silence errors. Sites with inline scripts or styles may need changes to their templates or a carefully maintained nonce or hash approach.
Find the right place to set them
Headers can be configured at several layers: a web server, a hosting control panel, a content delivery service, or an application. Use the layer you can maintain reliably, and check whether another layer already sets the same header. Duplicate or conflicting values can make behavior harder to understand. On a managed publishing platform, some settings may be controlled by the provider; look for supported configuration options before installing a plugin solely to add headers.
Apply changes to the responses that need them, not just the home page. A header shown on one page does not prove it appears on other pages, error pages, or resources served from a different hostname. Keep a short record of the values you chose, where they are configured, and why. That note will help when a future redesign adds an embed or a new service.
Test the site, then make security checks routine
If you have a staging site, try changes there first. Inspect response headers in your browser’s developer tools, then browse the pages people actually use: forms, search, downloads, account areas, and embedded content. Check the browser console for blocked resources and confirm that essential actions still work. A command-line request or header-checking tool can help confirm what the server sends, but a visible header alone does not show whether the site remains usable.
After publishing, revisit the checks whenever you change hosting, templates, plugins, or third-party services. A sensible first pass is to verify HTTPS, add and test simpler headers, review framing needs, and plan CSP separately. Small, documented changes are easier to maintain than a large set of rules nobody feels safe editing.
