Grafana security headers and CSP

The fix/etc/grafana/grafana.ini

[security]
content_security_policy = true
x_content_type_options = true
x_xss_protection = false
strict_transport_security = true
strict_transport_security_max_age_seconds = 31536000

The one that is backwards

x_xss_protection = true

That is Grafana’s default, and it is the only place on this site where a current, actively maintained project still enables X-XSS-Protection for you.

The header controlled a browser XSS filter that has been removed from every current browser, and while it existed it was harmful: attackers could craft URLs that made the filter misidentify legitimate scripts and selectively disable them, introducing a vulnerability on pages that had none. Our nginx, Apache and HAProxy pages all say to delete the line. Grafana sets it by default.

In fairness, the practical impact today is close to zero — no current browser implements the filter, so the header is inert rather than dangerous on a modern client. Set it to false anyway: it costs nothing, it stops the header appearing in scan reports, and there is no argument for sending a header whose only historical effect was negative.

This is rated low for exactly that reason. It is tidiness, not risk.

CSP is off by default

content_security_policy = false

Grafana ships a policy template but does not enable it. Setting content_security_policy = true activates the template already in defaults.ini, which is tuned for Grafana’s own frontend — it uses a per-request nonce and strict-dynamic, and permits the connections Grafana needs.

The template does include 'unsafe-eval' and 'unsafe-inline' in script-src, which is weaker than a CSP written from scratch would be. That reflects what Grafana’s frontend and its plugin ecosystem require; strict-dynamic means modern browsers largely ignore the unsafe entries in favour of the nonce. It is a meaningful improvement over no policy at all, which is the actual comparison.

Turn it on in report-only mode first and read what breaks:

content_security_policy_report_only = true

Plugins are the usual source of violations, since a plugin loading resources from an origin the template does not list will be blocked. That is the policy working, but it is better discovered from a report than from a blank panel.

What is already right

Two defaults do not need changing, and knowing that saves time:

• x_content_type_options = true — nosniff is already sent.
• allow_embedding = false — Grafana refuses to be framed by default, which is the clickjacking protection. If you enable it to embed dashboards elsewhere, add the permitted origins to the CSP via form_action_additional_hosts and a frame-ancestors directive rather than leaving framing open to everyone.

If a reverse proxy sits in front

Set each header in one place. Duplicated headers from Grafana and from nginx or Apache produce values the browser resolves in ways that are hard to predict, and for CSP specifically multiple policies are combined by intersection — each extra one can only further restrict, which produces breakage that looks like a CSP bug.

Where the proxy already sends a complete set, leave Grafana’s off. Where it does not, Grafana’s are fine. Just do not do both.

Verify it worked

Read what is actually sent, which is the only thing that counts:

curl -sSI https://grafana.example.com/login | grep -iE 'content-security-policy|x-content-type|x-xss|strict-transport|x-frame'

Expect a content-security-policy line, x-content-type-options: nosniff, strict-transport-security, and no x-xss-protection line at all.

Check for duplicates, which is the reverse-proxy failure mode:

curl -sSI https://grafana.example.com/login | grep -ci 'content-security-policy'

Expect 1.

Confirm the configured values, remembering environment overrides:

grep -E 'content_security_policy|x_xss_protection|x_content_type_options|strict_transport' /etc/grafana/grafana.ini
docker inspect grafana --format '{{range .Config.Env}}{{println .}}{{end}}' | grep -i 'GF_SECURITY'

While CSP is in report-only mode, watch the browser console on a dashboard that uses plugins — that is where violations show up first.

Before you apply this

CSP is the one that breaks things, and it breaks them as blank or broken panels rather than as an error, which makes it easy to attribute to something else.

Roll it out in stages:

# Stage 1 — observe only, nothing is blocked
content_security_policy = false
content_security_policy_report_only = true

# Stage 2 — once the console is clean
content_security_policy = true
content_security_policy_report_only = false

Exercise every dashboard that uses a plugin panel during stage 1. Plugins are the most common breakage, and an infrequently-viewed dashboard will not surface its violation until someone opens it weeks later.

If you have customised root_url or serve Grafana from a subpath, check that the template’s $ROOT_PATH substitution produced what you expect — the connect-src entry uses it for websockets, and getting it wrong breaks live panel updates specifically while everything else looks fine.

HSTS carries the usual one-way risk: a browser that has seen it will refuse plain HTTP for the full max-age and there is no quick way to undo that. Confirm TLS is working first, start with a short max-age, and only add includeSubDomains when every subdomain is on HTTPS.

Every change here needs a restart:

sudo systemctl restart grafana-server

Related

• Enable TLS and secure cookies — HSTS depends on it being right.
• nginx security headers — the full case against X-XSS-Protection.