Expert Tools

HTTP response headers aren't just plumbing - a handful of them tell a visitor's browser to actively defend itself: refuse plain HTTP, restrict where scripts can load from, block clickjacking, and so on. None of them are visible to a visitor when they're set correctly; they only become obvious by their absence, when something goes wrong that one of them would have stopped.

Explained, not scored

The Security Scanner on the main site gives these same six headers a technical score and letter grade. This page is deliberately the opposite: no score, just what each header actually does, what's realistically exposed while it's missing, and how to add it - written for someone who wants to understand and fix the gap, not just see a number.

If this site runs on a CMS

Every fix below is described as a server-configuration change (an .htaccess directive, for example), because that always works regardless of what's running on top. But if this site is built on WordPress, or another CMS, a security-headers plugin can often set most of these without touching server configuration at all - worth checking there first if server access isn't something you have (or want to touch).

What the Wizard tab does

Rule-based, not AI: it turns the Check tab's findings into an actual block to paste into your own .htaccess. Seven headers have exactly one defensible value and are written without asking anything, including a blanket-deny Permissions-Policy: nothing here needs the camera, microphone or similar unless a specific feature was built to use one, and that's a deliberate, later loosening rather than a default. Four need a question or an observation before they can be written safely - X-Frame-Options depends on whether this site is meant to be embedded elsewhere, Strict-Transport-Security (and especially its two stronger options) can break things in ways that aren't easily undone, and Cross-Origin-Embedder-Policy/Cross-Origin-Resource-Policy depend on whether the page loads resources from other origins that need to stay embeddable.

CSP is the one header this can't just fill in

Content-Security-Policy is the only header of the ten that determines how strong the overall result actually is, and the only one that can't have a single correct value handed to it. The Wizard fetches this one page and inventories where its scripts, stylesheets, images and fonts actually come from, then proposes a policy built from what was genuinely found rather than a bare default-src 'self'. This stays best effort by nature: one page, no JavaScript execution, and a linked stylesheet's own @font-face rules aren't visible from here. Test any generated CSP in a browser's report-only mode before relying on it.