DigitalBanzai Knowledge

Security Headers

What security headers do, why they matter, and how to read the scan result.

Italian version
Severity
Moderate
Estimated fix time
15-45 min
Technical level
Intermediate
Applies to
WordPressStatic HTMLApacheNginxCDN / Reverse Proxy

Quick answer

Security headers are instructions a server sends to a browser with a page. You do not see them during normal browsing. They tell the browser, for example, which resources it may load, whether it may show the page inside another site, and what information to send when you follow a link.

They can add preventive protections for visitors. If some are missing, certain restrictions may not be available; that alone does not mean the site is vulnerable or compromised.

What they can tell the browser to do

  • Content-Security-Policy (CSP): can limit where a page loads files such as scripts and images from, and which scripts it may run.
  • Strict-Transport-Security (HSTS): can make a browser use HTTPS, an encrypted connection, on later visits to the site.
  • X-Frame-Options: can limit whether another site shows the page inside an embedded frame, reducing some attempts to deceive visitors.
  • X-Content-Type-Options: can prevent a browser from treating a file as a different content type from the one the server declared.
  • Referrer-Policy: can limit how much of the previous page's address is sent when opening another destination.

Why they matter and how concerned to be

Without an applicable protection, the browser may have fewer ways to limit unwanted content, deceptive embedding, or sharing the address of a page a visitor viewed. For example, without a restriction on embedding, a page could appear inside another site to confuse visitors; other safeguards might still prevent this. The actual effect depends on the page and how each instruction is configured.

The guide displays Moderate; TrustyRunner reports a single applicable header missing from the observed response as a Low finding. These labels have different scopes and do not establish a vulnerability. They point to a preventive protection to review in the site's context, not an automatic emergency.

What TrustyRunner observes

TrustyRunner checks these five headers to show which preventive instructions appear in one specific site response: the final response reached by the request, including after redirects. It records whether each header is present, absent, or present but empty, along with the final protocol (HTTP or HTTPS) and response status. A redirect or error response can still be examined.

HSTS is not applicable if the final response uses HTTP, even when the header is materially present. If the request fails and no response can be examined, the check does not invent missing headers.

How to read the results

The result describes what appears in the examined response. A present header does not show that its value is valid or that the protection works as intended.

  • Applicable header absent: the observed response did not send it. It is a point to assess in that response's configuration.
  • Header present but empty: this is distinct from an absent header; the check keeps it as a separate observation.
  • Applicable header present: the check records it as present for that response, without establishing that its value is valid or has the intended effect.
  • Mixed results: some headers may be present while others are absent or empty; the summary does not certify overall site security.
  • Redirect, final HTTP response, or error status: these describe the path and response observed, not automatic evidence of a header problem.
  • Failed request: header data is unavailable; this is not evidence that headers are missing.
  1. Identify the response involved and check which configuration produces it: the site, the server, or a service that delivers pages, such as a CDN.
  2. If an applicable header is absent, first decide whether it is needed for the intended behavior of that page or response. For an empty value, inspect the configuration that produces it.
  3. Change one rule at a time and try it in a suitable environment or on representative pages. Some instructions can change how a browser loads resources or embeds content.
  4. If the response was unavailable or was not the one you expected, first obtain evidence from the correct response.

Limits of this check

The check concerns one observed final response, not every page, address, subdomain, server delivering the site, or variation offered to different visitors. A present header does not establish that CSP or HSTS is valid or effective; an absent header does not establish a compromise.

This check does not prove that the site is free of issues that allow unwanted code to be inserted (XSS) or users to be misled through embedded pages (clickjacking). It does not certify CSP, HSTS, or overall site security, or replace reviewing the configuration in its context.

Verify with a new scan

After a change, run a new scan and compare the newly observed final response: presence, absence, or an empty value may change. The comparison confirms only what the new response exposes to TrustyRunner within the scan scope.