Security Headers
Check which HTTP security headers a site sends and what to improve.
Security Headers checks which HTTP security headers your site sends and awards a grade from A+ to F — much like securityheaders.com. Every missing header comes with a ready-made recommendation, and warnings highlight the weak spots in your configuration.
What are HTTP security headers?
With every response, a web server sends the browser a set of HTTP headers — technical metadata describing the content. Some of them are security instructions: they tell the browser what must not happen on this page. Well-configured security headers neutralise entire classes of attacks — cross-site scripting (XSS), clickjacking, eavesdropping on unencrypted traffic — before any malicious script gets a chance to run.
It’s one of the cheapest investments in web application security: no code changes required, just a few lines in the server or CDN configuration. Even so, most sites on the internet don’t send even the basic set — something the scanner exposes mercilessly.
How to use the scanner
- Enter the site address — the domain is enough, e.g.
sycope.com. - Click ‘Scan’ — we fetch the response headers from our server.
- Read the result — the big grade letter (A+ to F), chips showing present and missing headers, a list of gaps with recommendations, and warnings about values worth improving. At the bottom you can expand the raw response headers.
The grade rises with the number of key headers in place; the top A+ requires the full set, including HSTS ready for preloading. Warnings don’t drag the letter down as hard as outright gaps do, but they flag configurations that weaken protection — such as unsafe-inline or unsafe-eval directives in the CSP policy.
The headers that matter most, and what they protect against
- Strict-Transport-Security (HSTS) — enforces HTTPS: after the first visit, the browser will never again attempt an unencrypted connection, which kills SSL-stripping attacks. With the
preloaddirective, the domain can be submitted to the list built into browsers. - Content-Security-Policy (CSP) — defines where scripts, styles and images may be loaded from. It’s the most effective barrier against XSS, and also the trickiest header: a policy with
unsafe-inlineweakens the protection to almost nothing. - X-Frame-Options — forbids embedding the page in a frame on other sites, blocking clickjacking — the trick of planting invisible buttons under the user’s cursor. Its modern successor is the
frame-ancestorsdirective in CSP. - X-Content-Type-Options — the value
nosniffstops the browser guessing content types, cutting off tricks where malicious files masquerade as images. - Referrer-Policy — controls how much information about the source address leaks when following links to other sites.
- Permissions-Policy — switches off browser APIs you don’t need (camera, microphone, geolocation), shrinking the attack surface.
The legacy X-XSS-Protection is no longer required — modern browsers have removed that mechanism, and protection against cross-site scripting has been taken over by CSP.
How to deploy the missing headers
Headers are added in the web server configuration — in Apache via Header set in the vhost config, in nginx via add_header, and when using a CDN (e.g. Cloudflare) in the service’s dashboard. For every gap, the scanner provides a safe starting value you can paste straight into your configuration.
Order matters: start with the painless ones — X-Content-Type-Options, X-Frame-Options and Referrer-Policy — then enable HSTS (with a short max-age at first, working up to a year plus preload), and roll out CSP last — ideally in stages, beginning with report-only mode (Content-Security-Policy-Report-Only), which logs violations without blocking anything. Re-scan the site after every change.
Keep in mind that headers protect the user’s browser, but they’re no substitute for monitoring the infrastructure itself — effective defence pairs application hardening with the network traffic visibility that NDR-class systems like Sycope provide.
Frequently asked questions (FAQ)
What does an F grade mean?
The site sends none of the key security headers. The browser receives no protective instructions, leaving users to rely solely on its defaults. These gaps are worth closing first — they’re configuration changes, not development work.
How do I get an A+?
You need the full set of key headers, including Strict-Transport-Security with a long max-age and the includeSubDomains and preload directives — i.e. a configuration that qualifies the domain for the browsers’ preload list.
Can CSP break my site?
It can — an overly strict policy will block scripts, styles or fonts the site depends on. That’s why CSP is rolled out in stages, starting with Report-Only mode and reviewing the violation reports before enforcement is switched on.
Why does the scanner warn about unsafe-inline?
The unsafe-inline directive allows scripts embedded directly in the HTML to run — which is precisely the vector XSS uses. A CSP policy with this directive protects far less; the long-term fix is to replace it with nonces or hashes.
Do these headers affect SEO or page speed?
Speed — practically not at all; it’s a few hundred bytes per response. Indirectly they help: HSTS eliminates needless redirects on return visits, and a secure, HTTPS-served site is the baseline search engines expect.
What’s the difference between X-Frame-Options and frame-ancestors?
Both mechanisms block the page from being embedded in frames. X-Frame-Options is the older, simpler header (DENY/SAMEORIGIN), while frame-ancestors in CSP offers precise control — for instance, allowing embedding only from specific domains. Sending both is the safe choice.