Security Headers

What it is

Security headers are instructions sent by the server to the browser. If they are missing, the site is not using some common browser-side protections. Adding them can help reduce risks such as clickjacking, MIME sniffing, referrer leakage, and uncontrolled resource loading, but some headers, especially CSP and HSTS, need to be configured carefully and tested.

Why it matters

Security Headers are HTTP headers included by the server in the response sent to the user's browser. They are directives that help the browser handle content, frames, referrers, and connections more cautiously.

It is important to be clear that these headers do not provide total protection for a site. They are a browser-side defense layer: they can reduce certain client-side risks, but they do not replace server security, CMS hardening, or secure application code.

Missing headers do not mean the site has been compromised, but they do leave out some defensive controls that are often worth enabling.

Security headers can help:

Reduce clickjacking (X-Frame-Options): they limit the chance of the site being loaded inside unwanted iframes.
Reduce MIME sniffing (X-Content-Type-Options): they tell the browser to respect the content type declared by the server.
Limit referrer leakage (Referrer-Policy): they control how much URL information is sent to external sites.
Limit unexpected resource loading (Content-Security-Policy): they define which origins the browser may use for scripts, images, styles, or fonts.
Reinforce HTTPS usage (Strict-Transport-Security): they tell the browser to use HTTPS for future visits.

These headers help, but they do not make a site secure on their own. In the same way, their absence does not mean total insecurity: they should be understood as one part of the wider technical setup.

Note: security headers do not replace CMS updates, security patches, backups, access protection, or broader hardening practices.

How CyberLens checks it

CyberLens sends an HTTP request to the analyzed response and checks only the presence of these 5 recommended headers:

Content-Security-Policy
Strict-Transport-Security
X-Frame-Options
X-Content-Type-Options
Referrer-Policy

The current check therefore reports which of these headers are present or missing in the observed HTTP response.

It is important to clarify that CyberLens, today, does not yet perform a full validation of the internal quality of the directives, especially for headers such as:

Content-Security-Policy, which may be present but too permissive or too restrictive;
Strict-Transport-Security, which may be present but not necessarily appropriate for the real domain or subdomain setup.

In other words, presence is detected, but configuration quality still requires manual review.

Possible findings

Many recommended headers are missing: the server is not sending several browser-side protection instructions. This is useful to improve, but it does not by itself imply a compromise.
Some headers are present, others are missing: partial configuration. This is often the most common scenario.
The recommended headers are present: a good basic configuration signal, but not enough on its own to prove the directives are correct or suitable for the site.
A header is present but needs manual review: for example, CSP or HSTS may exist, but they still need to be checked carefully before being treated as well configured.

Recommended action

Start with the simpler headers: X-Content-Type-Options, X-Frame-Options, and Referrer-Policy are often good first actions.
Use HSTS carefully: enable it only when HTTPS is stable across the relevant domain and included subdomains.
Treat CSP as a configuration to adapt: a policy that is too strict can block legitimate scripts, fonts, maps, analytics, or other components.
Test after every change: check pages, forms, login flows, checkout flows, embeds, and external resources.

How to fix it

1. WordPress

If you use WordPress, you can apply these headers in different ways: plugins, hosting panels, CDN rules, or server configuration.

The important point is not to treat security headers as an automatic checkbox. Even when a plugin or graphical panel applies them, the rules still need to be understood and tested.

After enabling them, check in particular:

contact forms;
ecommerce checkout flows;
external fonts;
embedded maps, videos, or widgets;
access to the admin area.

For CSP, avoid prebuilt policies applied without review: if your theme or plugins load external resources, an overly restrictive rule can break parts of the site.

2. Apache / .htaccess

If the site runs on Apache or you can manage the .htaccess file, you can start with a cautious setup like this:

<IfModule mod_headers.c>
  Header always set X-Content-Type-Options "nosniff"
  Header always set X-Frame-Options "SAMEORIGIN"
  Header always set Referrer-Policy "strict-origin-when-cross-origin"

  # Use HSTS only if HTTPS is stable across the full domain
  # and included subdomains.
  Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

  # Restrictive starting point to adapt and test.
  Header always set Content-Security-Policy "default-src 'self';"
</IfModule>

X-Content-Type-Options, X-Frame-Options, and Referrer-Policy are often good first actions.

For Strict-Transport-Security, use caution: it is appropriate only if the site is served correctly over HTTPS in a stable and consistent way.

For Content-Security-Policy, default-src 'self' is only a restrictive starting point. It is not a universal rule: it needs to be adapted and tested based on the real resources used by the site.

3. Nginx

If you manage Nginx directly, you can place similar directives inside the server block:

add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;

# Use HSTS only if HTTPS is stable across the full domain
# and included subdomains.
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

# Restrictive starting point to adapt and test.
add_header Content-Security-Policy "default-src 'self';" always;

After each change:

test the syntax with nginx -t;
reload the service;
verify that the site still works correctly.

Here too, X-Content-Type-Options, X-Frame-Options, and Referrer-Policy are often the simplest first steps. HSTS and CSP require more care.

4. CDN / Hosting Panel

Many hosting panels or CDN services let you add these headers through a graphical interface, without editing server files directly.

Even in that case, it is wise to:

document the previous setup;
apply only a few changes at a time;
verify the site's behavior immediately;
keep a rollback path ready in case something breaks.

How this appears in CyberLens

In the CyberLens report, the check shows a practical summary and a technical details block.

User interface:

Check: Security Headers
Status: 0 / 5 recommended security headers detected.
Message: Add the missing recommended headers to strengthen browser-side protection.

Technical details (JSON):

{
  "total": 5,
  "present_count": 0,
  "missing_count": 5,
  "present_headers": [],
  "missing_headers": [
    "Content-Security-Policy",
    "Strict-Transport-Security",
    "X-Frame-Options",
    "X-Content-Type-Options",
    "Referrer-Policy"
  ]
}

This means that CyberLens, today, mainly exposes:

how many of the 5 recommended headers are present;
how many are missing;
the list of present headers;
the list of missing headers.

It should not be interpreted as a full validation of the internal quality of CSP or HSTS.