Header Advisor
Learn the Content Security Policy an application really needs from the browsers of its own users, deploy it with confidence, and keep it current as the application changes.
WASViking® Header Advisor writes the Content Security Policy (CSP) an application needs from evidence, not from guesswork. You add one report-only header at your edge or origin. The browsers of your own users then report every script, style, font, image, frame, API call and inline block the application loads, page by page. From that evidence the platform proposes the policy, grades it, detects when you deploy it, tells you when the application changes and the policy has to follow, and separates legitimate change from injected content.
The problem it solves
A missing or weak CSP is one of the most common findings on any web application, and one of the hardest to close. The policy has to list every origin the application loads, including the ones added by tag managers, chat widgets, payment providers and a decade of front-end decisions nobody documented. Written by hand, the first draft breaks the application or ends up so permissive it protects nothing. Written once, it goes stale the next time the marketing team adds a script.
Header Advisor turns that into a measured process. The application keeps running while the policy is learned. The proposal is built from what real users loaded, with the decisions that need a human called out explicitly. After deployment the same evidence stream keeps the policy honest.
How it works
- Add the discovery header. The portal gives you the exact header
names and values for your platform. The header is
Content-Security-Policy-Report-Only, which never blocks a request; it only asks the browser to report what the page loads to the WASViking collector. - Learn from real traffic. Every page your users open adds evidence. Each source is aggregated by directive and origin with the days it was seen, the number of distinct browsers, the pages it appeared on and a sample of what was blocked. The learning window is seven days by default; the policy is also ready earlier when no new source has appeared for three days.
- Review and approve. The proposal lists every source with a
verdict and the reason behind it. Inline scripts, inline event
handlers, inline styles,
evaland blob workers each get a decision card with the options and their impact on the grade. The policy is graded with the same grader the scan engine uses for security headers, so the advisor and your findings never disagree. - Deploy in two moves. Copy the approved policy as report-only
first. WASViking recognises it from the browsers' own reports and
marks the advisor as a candidate; after three clean days you
rename the header to
Content-Security-Policyand the advisor becomes enforced. Deployment is detected, not declared. - Keep it current. Analysis runs every ten minutes. A new legitimate source that reaches quorum after deployment becomes an update waiting for review, with a ready diff for the next version. Content that does not belong to the application becomes a threat signal instead.
What you see
| Screen | What it shows |
|---|---|
| Header Advisor (list) | One card per hostname with its status, the headline (sources to review, open threat signals), reports in the last seven days, the approved version and its grade. |
| Step 1: Add the discovery header | Header names and values with a walkthrough for Cloudflare, Google Cloud Load Balancer, nginx, Apache, IIS, Node.js (Express), Next.js, Django, Spring Boot and ASP.NET Core, plus Check header to confirm the hostname already sends it. |
| Step 2: Learning from real traffic | Day counter, sources, pages seen, distinct browsers, new sources in the last 24 hours, stability, and the source table with verdict, classification, evidence and reputation. |
| Step 3: Review and apply the policy | The proposed or approved policy one directive per line, its grade, the decision cards, the rollout in two moves and the per-platform snippets. |
| Deployment and monitoring | Reports, noise filtered, drift pending and open threat signals; the deployed version and disposition as seen by the browsers; the review changes list with the diff for the next version. |
| Threat signals | Injected inline scripts, look-alike domains, sources pulled by addresses Edge Threat Radar flags, each with severity, page, sample and an acknowledge action. |
| Policy history | Every version with status, grade, source count and dates. |
Verdicts
| Verdict | Meaning |
|---|---|
| Recommended | Reached quorum (days and browsers) and passed the reputation check. Included in the policy. |
| Needs your decision | Inline code, eval, blob workers or a host under a frequently abused top-level domain. A decision card or an explicit include is required. |
| Watching | Seen, but below quorum. Not included yet. |
| Excluded | Excluded by you. Kept in the evidence so the exclusion is visible. |
| Threat | A look-alike of your own domain, an address literal, a punycode label or a source pulled mostly by addresses Edge Threat Radar flags as attackers. Never proposed. |
Quorum scales with the audience: a source has to be seen on at least three days by a share of the observed browsers, with a floor of three and a cap you set. A staging or internal application with fewer than ten browsers runs in a low-traffic mode with a quorum of one, so it can still get a policy.
Sources the catalog completes
Around fifty documented services are known to the advisor: tag managers, analytics, fonts, CAPTCHA and challenge platforms, payment providers, chat and support widgets, error tracking, identity providers and CDNs. When the browsers report one of them, the directives its documentation requires are completed automatically, so the first deployment does not break a checkout because a provider loads a frame the learning window never saw.
Hardening grade
Every proposal and every approved version carries a grade: Strong,
Partial, Weak or Missing, with the reason. unsafe-inline
and unsafe-eval count as weak only where they weaken script
protection; unsafe-inline for styles alone is partial. The decision
cards show the impact of each option before you approve, and the
hashes of your inline scripts and styles are computed from your pages
when the hostname is reachable, so the strong option is one click when
the application allows it.
Safe by design
- Report-only never blocks. The discovery header and the candidate header only ask the browser to report. Nothing the application loads is affected.
- Reports travel out of band. The browser sends them after the page has loaded and drops them silently if the collector is unreachable. An outage on the WASViking side costs an interval of learning, never a request on your side.
- Deployment is detected from evidence. The platform never writes to your edge or origin. You copy the header; the browsers confirm it.
- The enforcing move is yours. Enforcement is a separate, deliberate step, taken after the candidate ran clean.
What is collected
Reports carry the page path (no query string), the directive, the blocked source and, for inline code, a short sample of at most 160 characters. The collector aggregates them per source; raw reports are not stored. Browsers are counted through a keyed weekly fingerprint, never by raw address. Reports for a hostname other than the one being advised are dropped, and the collector rate-limits per hostname and per client. Retention of the aggregates follows your plan.
Alerts
One event type, Header Advisor, available on every notification channel (Slack, Microsoft Teams, email, API). It fires when a policy is ready for review, when an update is waiting after deployment and when a new threat signal appears. Opt in per channel under Notification Channels.
What this is not
It is not a JavaScript snippet on your pages. Header Advisor adds nothing to the application and cannot slow it down.
It is not an automatic deployer. Applying the policy at your edge or origin stays in your hands, with the exact value to paste.
It is not a web application firewall. It shapes what the browser is allowed to load; it does not inspect traffic.
Plan availability
| Plan element | Notes |
|---|---|
| Monitored hostnames | Pro: 1. Business: 3. Enterprise: negotiated. One advisor per hostname; subdomains of your targets are accepted. |
| Evidence retention | Pro: 30 days. Business: 90 days. Enterprise: negotiated. |
| Roles | Admin and Manager start, approve, pause and remove advisors. Analyst and Read only view them. |
Where it lives in the portal
- Edge Threat Radar → Header Advisor: the list, each advisor's three steps, monitoring, threat signals and history.
- Vulnerabilities → Security Headers: the Content Security Policy finding offers to start the advisor for that hostname.
- Notification Channels: the Header Advisor event on each channel.
Set up
Follow Set up Header Advisor: add the hostname, deploy the discovery header on your platform, watch the learning window, approve and roll out the policy in two moves.