HTTP Security Headers & Content Security Policy

On every response, the Athena web console sends a fixed set of hardening headers — a strict Content-Security-Policy, clickjacking and MIME-sniffing protections, a referrer policy, a browser-feature policy, and (over HTTPS) an HSTS header. This page lists each header, its exact value, and what it means for vulnerability scans, embedding the console, and running behind a reverse proxy.

The headers Athena sends#

Every HTTP response from the console and API carries the following headers. HSTS is the one exception — it is added only over HTTPS in a production deployment (see HSTS).

Content Security Policy in detail#

The Content-Security-Policy header is the strictest of the set. Its full value is:

default-src 'self';
script-src 'self';
style-src 'self' 'unsafe-inline';
img-src 'self' data:;
font-src 'self';
connect-src 'self' ws: wss:;
frame-ancestors 'none';
report-uri /api/csp-report;

HSTS (HTTP Strict Transport Security)#

In a production deployment served over HTTPS, Athena adds a Strict-Transport-Security header with a one-year max-age (31536000 seconds). Once a browser sees it, that browser will only ever contact the console over HTTPS for the next year, even if a user types http:// or clicks a plaintext link.

• Subdomains are not included — the policy applies only to the exact host the console is reached on, which suits an internal deployment reached by IP or a single hostname.
• Not preloaded — Athena does not submit the host to the browser HSTS preload list, so nothing about your internal hostname is published externally.

CSP violation reports#

The CSP's report-uri points browsers at POST /api/csp-report. Whenever the policy blocks a resource — a legitimate misconfiguration, or an attempted injection — the browser sends a small JSON report there. Athena records it to the server log:

• An ordinary violation (for example a blocked inline style during development) is logged at warning level with the violated directive, the document, and the blocked URI.
• A violation whose blocked resource looks like an external script-injection attempt is escalated to a critical log entry with the client IP address, so it stands out in monitoring and in any forwarded log stream.

The endpoint accepts anonymous, unauthenticated POSTs (browsers send reports without credentials) and always returns a plain 200 OK with no body, so it never leaks information back to a caller. There is nothing to configure and no UI for it; watch your server logs — or your forwarded log stream — to see reports as they arrive.

Behind a reverse proxy#

Athena terminates TLS itself and needs no reverse proxy, but many sites place one in front for TLS offload or a shared virtual IP. When you do, keep these points in mind so the security headers survive the hop:

• Don't strip or override the headers. Athena sets each header on the origin response. A proxy that rewrites Content-Security-Policy, drops X-Frame-Options, or injects a second, weaker copy can silently loosen the console's protections. If your proxy adds its own security headers, make sure it does not duplicate or relax the ones above.
• Preserve the WebSocket upgrade. The CSP allows ws:/wss: because the console keeps a live connection open for real-time updates. A proxy that does not forward WebSocket upgrades will break those updates even though the CSP permits them.
• Trust forwarded client information explicitly. Athena honors X-Forwarded-For and X-Forwarded-Proto only from proxies on its trusted-proxy allowlist; otherwise it ignores them and records the proxy's address. This keeps per-IP throttling and the audit trail honest. Configure the allowlist as described in Server TLS Certificate → Behind a reverse proxy using Security:TrustedProxies (individual IPs) and/or Security:TrustedProxyNetworks (CIDR subnets).

Vulnerability scans & verification#

A quick way to confirm the headers reach the browser is to request any console URL and inspect the response headers:

# View the security headers on any console response
curl -sI "https://athena.example.com:8443/login"

You should see Content-Security-Policy, X-Frame-Options: DENY, X-Content-Type-Options: nosniff, Referrer-Policy, Permissions-Policy, X-XSS-Protection, and — over HTTPS — Strict-Transport-Security. If a header is missing in the browser but present here, a proxy or gateway between you and Athena is stripping it.