Changelog

The header block’s Document-Policy-Report-Only line asked Chrome for nothing, so it is gone, and a site that pasted it can remove it. Document policy reports still arrive from a Document-Policy your site serves, with ;report-to= and the endpoint’s name on each feature, as the browser report types guide shows.

Policy › Draft now suggests a name for a third-party host that is not on our list of known vendors, marked “Suggested by AI” with a sentence on what it does. The suggestion comes from Claude on Amazon Bedrock, which is sent only the host name and the kind of resource it served. It is a label: it never adds a source to your policy, leaves one out or clears a flag. A name that does not match the domains we know that company uses is dropped, so a look-alike domain stays unknown.

Policy › Frames lists each origin your pages tried to load in a frame under frame-src, from a policy discovery run or from your policy refusing it, on every plan, newest first. On a checkout that is usually your payment provider’s card fields. When your policy refuses a new one, a rule covering new framed origins is told, and the alert leads with it when the frame was on a payment page.

Policy › Destinations lists each host your pages tried to send data to under connect-src or form-action, from a policy discovery run or from your policy refusing it, on every plan. Each keeps the date it was first seen after its reports expire, and on the Professional plan and above a filter narrows the list to what your payment pages talk to.

An issue’s drawer now starts with a decision. Mark it expected and it leaves the Issues list and the Overview and never alerts. Mark it fixed and it reopens on its own when a report arrives after the fix. A new issue now alerts once; while it lasts, it is in your digest.

When your policy’s connect-src or form-action refuses a host, and enough browsers report it to be real, HeaderHawk now sends a New data destination alert, on every plan, instead of a new CSP issue. It says whether a policy discovery run saw the host before your policy refused it. A rule covering every event hears about it already; a rule that names New CSP issue needs New data destination added to keep hearing about these.

Choosing a plan during sign-up, upgrading from Billing and adding a card all stopped with a “not a valid URI” error before reaching checkout. They go straight to checkout again.

The last step of signing up now starts policy discovery for the site you added, and hands you its headers instead of a starter policy. For two weeks your visitors’ browsers report what your pages load, and the Overview takes it from there: a proposed policy, report-only, then enforced. The starter policy is still in the site’s setup if you would rather write your own.

Each third-party source in a proposed policy now says who it belongs to, such as Stripe for payments or Google Fonts. A source that looks wrong is flagged with the reason and left out until you keep or drop it: one that appeared late in the run, one seen only on your payment pages, or one a letter away from a vendor you already use.

On the Professional and Business plans, Scripts › Payment pages has a Policy view. It turns your script decisions into a Content-Security-Policy for your payment pages: each pinned version allowed by its hash, each script you authorized for any content by its URL, and nothing you rejected. It comes report-only first, with the integrity attribute each pinned script’s tag needs.

The Overview now shows each site’s next step: start policy discovery, review the policy it proposes, run it in report-only, then enforce it, and after that the browser change and isolation headers. Each step waits until your reports say the last one has settled. A site’s setup shows the headers its step asks for, with every report type still under All report types. A new site starts with only what its first step needs, and a newly switched-on security policy type sends its first week of issues to your digest rather than your inbox.

Policy › Draft runs discovery on any site, on every plan: one extra report-only header that allows nothing, so for a week your visitors’ browsers report everything your pages load. HeaderHawk then proposes a policy one directive at a time, each source with the browsers, pages and dates behind it, and flags inline scripts and eval, never allowing them. Keep or drop each source, watch the grade change, and copy the result as a report-only header.

On the Professional and Business plans, an owner or admin can create API keys under Settings › API keys and read sites, issues, reports, scripts and scans from a versioned, read-only API. The same data is available to Claude, ChatGPT, Cursor, Codex and Claude Code through HeaderHawk’s hosted MCP server: add one URL and sign in. The docs site has a page for each assistant.

HeaderHawk has a logo: a blue header row. It runs over the name in the website’s header, the docs and every link preview we generate. On the browser tab, for the website, the docs and the dashboard, it sits over two H’s.

SAML single sign-on is now part of the Business plan, including its trial, so you can set it up from Settings without an Enterprise contract. Point HeaderHawk at your identity provider for the email domains you have verified, and require it for those domains when you are ready. Moving from the Business plan to the Professional plan removes the connection, and the dashboard warns you before you confirm.

The site scanner no longer lists good news as findings. A year or more of HSTS, a domain on the browser preload list or waiting to join it, and a domain that could be preloaded but has not asked to be now say nothing. A page that adds a <meta> Content Security Policy beside a reporting header no longer reads as having no reporting endpoint. No grade changes, and results carry rubric version 5.

On the Professional plan and above, a site’s setup panel now has a report host name: pick acme-shop and the site also reports to https://acme-shop.ingest.us.headerhawk.com/r, and the header block the panel writes uses it. The generated URL keeps working beside it. A name you choose stays your organisation’s even after you release it, so nobody else can receive the reports of headers that still name it, and it keeps working if you change plans. An organisation can hold up to 25 names, released ones included.

Ticking “Also accept all subdomains” beside dev.example.com now adds *.dev.example.com, and the checkbox names that host. Before, it added *.example.com, which accepted reports from every host under your domain. The discarded-reports panel likewise offers the wildcard one level above a host, not over the whole domain. Host lists you have already saved are unchanged: a wider wildcard saved before shows as its own row, so you can see it and remove it.

A new site’s report URL is now https://<code>.ingest.us.headerhawk.com/r, with the site’s ingest code at the front of the host, and its setup panel shows it. Sites added before today keep the URL they were given, and it keeps working.

The Team, Professional and Business plans each start with a free trial that needs no card, so the payment-page features can be tried on the plan that has them. Every plan’s monthly report allowance is larger, and the Professional and Business plans keep reports for longer.

Every site’s setup panel now shows a report URL at its own host, https://<code>.ingest.us.headerhawk.com/r. A site added before this week keeps the URL it was given as well: the panel names it under the new one, and headers that already use it need no change.

Searching the docs returned nothing, and choosing a light or dark theme did nothing, because the docs site’s own Content Security Policy was blocking the scripts behind both. The policy now allows exactly those scripts by hash, and nothing else, so both work and the site still grades A+ in our own scanner.

When a new version of a script appears on a site with payment pages, HeaderHawk now fetches it and keeps the file if its SHA-256 matches the one your visitors’ browsers reported, so months later you can open the exact code that ran, long after the vendor has replaced it. Owners and admins download a copy from the script’s drawer, and every download is recorded with who and when.

A file changed before HeaderHawk fetched it is shown as a mismatch, with the fingerprint of what the server sent instead, rather than kept. Copies are held for twelve months and are stored, not analysed. This is on the Professional plan and above.

Scripts now has an Integrity tab. It counts which scripts browsers are checking against a hash and which they are not, shows the Integrity-Policy-Report-Only header for your site, and lists every script loading without integrity metadata. Where browsers reported one version of a script, the list gives you the integrity attribute to paste into its tag; where they reported several, it says why one attribute would break and opens the script so you can pin the versions you trust instead.

A chart shows how many scripts were reported unprotected each day over the last 30 days, so you can watch the count fall as you add hashes. This is on the Team plan and above.

The daily scan of a payment page now alerts when a script it had found there in three scans in a row is missing from two in a row, and when a script goes missing as a file with the same name starts loading from a different host, which arrives as one alert naming both. It is decided from the scan and never from browsers going quiet, so a script that is only cached raises nothing.

A script that has left stays in the inventory, marked missing with the date it was last found, and the alert history now says what each alert was about. Rejecting a script you removed on purpose keeps it quiet. This is on the Professional plan and above.

The Overview used to open on how many reports arrived. It now opens on what needs a decision this week: new policy issues, scripts on your payment pages nobody has authorized or rejected, scripts with a known vulnerability, scripts loading without integrity checks, header grade drops and error spikes, each linking into the section where you act on it. Below the counts, one list gathers the newest of those with a link that opens each one, and every number follows the site you choose in the header.

A count your plan does not include shows which plan does instead of a lock: the payment-page review queue, known vulnerabilities and header grade drops are on the Professional plan and above, and scripts without integrity checks on the Team plan and above.

Headers now has a Changes tab: every daily scan that found a security header added, removed or changed, or a lower grade, across all of a site’s watched pages, newest first, each one opening the scan that found it. The Pages tab says what each page’s latest scan changed, in the same words your digest uses, and the Changes tab counts the week’s changes so they show from either tab. Pages are scanned on the Professional plan and above.

HeaderHawk now collects connection allowlist reports, which name a connection a page made to an origin its Connection-Allowlist header does not allow. Issues lists them by that origin, and the site setup generates the header. Chrome sends each report when the visitor loads another page on your site.

Your Scripts view used to answer “what is this script?” with a base64 digest. Where those exact bytes are a file a published npm package contains, it now says so instead (jquery 3.7.1, and the file inside the package) with the hash still beside it as the evidence. The match is on the contents, not on the URL or the file name, so a file renamed on the way to your CDN is named by what it is.

Scripts we cannot name read “Unrecognised”, which is the normal and permanent answer for your own build output and is never treated as a problem; a new filter narrows the list to them so a review can start there. A script loaded without CORS reads “Cannot be identified”, because the browser sent no bytes to check. And where a URL asks npm for one package while its bytes are another package’s file, the drawer asks about it rather than raising an alarm.

The names are in the payment-page CSV export too, next to the digests. This is on the Team plan and above, with the rest of the script inventory.

When the Scripts view names a library version, it now checks that version against the advisories published for it, from OSV and the GitHub Advisory Database, and shows each one with its severity, the release that fixes it and a link to the source. The check runs when a script is first seen and again every day, so an advisory published today reaches a script that has been running for months, including the tag manager’s and vendor scripts no lockfile lists.

A high or critical advisory raises an alert once, immediately or in your digest, and a filter narrows the list to the affected scripts. The payment-page CSV export carries the advisories beside each script. An advisory is about the version, not how your page uses it, and a script we cannot identify reads “Not assessed”, never clean. This is on the Professional plan and above.

Every day, the scan of each payment page now fetches every script the page’s HTML names and records a hash of what it served in your script inventory, beside what browsers report. A script every visitor has cached, one loaded without CORS, and a checkout nobody visited that week all get a hash, and a scan hash can be pinned where browsers could send none. Each version says whether browsers, the scan or both saw it, and a page’s scan history lists that day’s scripts.

A new or changed script the scan finds on a payment page alerts on that scan, with no wait for browsers on a second network. The scan runs no JavaScript, so a script another script adds while the page runs is still seen only when browsers report it. This is on the Professional plan and above.

The dashboard has a Compliance section. For one site at a time, it says whether PCI DSS 4.0 requirements 6.4.3 and 11.6.1 are met, partially met or not met, shows what each status rests on, and lists what is missing, with a link to the page where you fix it. Once the site has payment pages, each requirement’s evidence exports as a dated CSV you can hand an assessor.

It is on every plan. Where a plan cannot meet a requirement, the page says so and names the plan each missing step needs.

An organisation on the Enterprise plan can point HeaderHawk at its own SAML identity provider from Settings → Authentication, for the email domains it has verified. Anyone signing in with an address at one of those domains is sent to the provider; everyone else gets the emailed code exactly as before, and so do your own people if they prefer it. There is one sign-in field and no separate button to find: the address decides where it goes. Someone signing in for the first time joins as a member, and an administrator can change their role afterwards in your settings.

A scan now shows, beside the grade, which browser report types the page requests and the header asking for each, with a link to the one it is missing. It does not change the grade.

A script your policy blocked from a data: or blob: URL used to be hidden as noise. It now stays on the Issues page, marked Noise, because it can be an injection as well as an extension. It still never raises an alert on its own, and data: images and fonts stay hidden as before.

Every page now says what HeaderHawk is for: the code that runs in your visitors’ browsers, the policies browsers enforce on it, and the record that those policies held. There is a new page explaining what client-side security means, which controls exist, and what a firewall or a log pipeline cannot see, and the features page is organised as see, control and prove, with the plan named wherever a capability starts partway up.

HeaderHawk now collects the browser’s other reports alongside CSP: integrity, COOP, COEP, Permissions Policy and Document Policy violations in Issues, deprecations and interventions on Browser changes, and network errors and crashes on Reliability. Each type has its own switch and sample rate, on every plan including Free.

A site’s setup now shows its report type switches above the headers to copy, and the headers ask browsers for exactly the types switched on. Turn script hashes off and 'report-sha256' leaves the policy before you save, so you stop paying for reports you no longer want. Every header is report-only and points at your site’s /r/ endpoint. A new docs guide lists each report type and the header that requests it.

On the Professional plan and above, the Scripts page has a Payment pages tab: every script browsers reported on the pages you mark as payment pages, and a review queue of the ones nobody has decided about. Authorize or reject each with a written justification, pinning the versions you reviewed or accepting any content from that URL. Every decision is kept with who made it and when, and the inventory exports as a CSV for your assessor. You are alerted when a new script runs on a payment page, when a pinned script runs a version you did not pin, and when a rejected one runs there again, once browsers on two different networks have reported it.

A site’s edit dialog now has a Report types section: a switch and a sample rate for each kind of report the site sends, starting with CSP violations and script hashes. Script hash collection is switched off with its own toggle rather than a 0% rate, and a change reaches ingestion within a minute.

Reports now go to https://ingest.us.headerhawk.com/r/ followed by your site’s ingest code, and that is the address your site’s setup gives you. The host says where your reports are received and stored, and /r/ takes every report type. The old ingest.headerhawk.com/csp/ address no longer accepts reports, so copy the endpoint from your site’s setup panel if your headers still use it.

On the Professional plan and above, each site now has a Payment pages list: mark the checkout pages PCI DSS cares about, starting from the pages the site already reports from, with a pattern for URLs that change per session. The Issues list, the Reports explorer and the Scripts page can then show payment pages only, including reports that arrived before you marked them, and an alert rule can be limited to them.

Every violation report quotes the Content-Security-Policy that was in force, and HeaderHawk now remembers the policies each site reports. When a new one appears, an alert says what changed and from what, on every plan; each site’s policy history is under Settings, Sites. On the Professional plan and above, the pages you mark are also scanned every day with the free site scanner’s rubric, and you are alerted when a security header is added, removed or changed, when the grade drops, or when a page cannot be scanned three days running.

A new Browser changes page lists the browser APIs your pages use that the browser is deprecating or has intervened in, soonest removal date first, with the script and line that used each one and the pages it ran on. A date within 60 days is highlighted, and one already passed says so. Deprecations also get a panel on the Overview and can be opened in the Reports Explorer. They are kept at 5% by default, so the counts are estimates, and the site’s setup headers now name the default reporting endpoint these reports need.

Alerts no longer need repeating for every site. Settings → Alerts now has rules, each written as a sentence you can check at a glance (“New CSP issue on all sites → Organization admins, immediately”), and destinations set up once and used by any rule, whether that is an email list, a Slack channel or a webhook. Test a destination and the result appears beside it, with the reason when something refuses it, and History says what was sent where and whether it arrived. If no rule covers a site, the Issues page says so and offers a rule already scoped to it.

A site can now accept reports from a list of hosts instead of one. Add checkout.example.com beside www.example.com, or *.example.com to cover every subdomain, and tick “Also accept all subdomains” when you create a site. When reports from a host you forgot are discarded, the setup panel names it and lets you allow it in one click.

A scan used to say your Strict-Transport-Security was short. It now gives you the header line to serve next: one step of a ramp rather than the finished header, because a browser holds the max-age you hand it and there is no taking it back from the visitors who already have it. It also reads the header the way a browser does, so a repeated one, a max-age=0 and an HSTS header on a plain-HTTP response each get a finding of their own.

Where the preload list is a live question, the scan checks every requirement it can and says which ones one fetch of one URL cannot, and it asks hstspreload.org whether the domain is already on the list, sending the hostname and nothing else.

The site header now has a Log in link beside Sign up free, on desktop and in the mobile menu, so getting back to your dashboard no longer means clicking a button that says you are signing up.

Enter a URL at headerhawk.com/tools/site-scanner/ and get a letter grade for its Content Security Policy and security headers, the one reason the grade is capped where it is, and findings that each say what to change and why. The rubric behind the grade is published on the docs site. No account needed; results are kept for thirty days at a link you can share.

headerhawk.com now renders on a white page rather than navy, with the dark band kept for the homepage hero and each page’s closing call to action. The product screenshots on the homepage were retaken in the dashboard’s light theme to match.

The hash generator at headerhawk.com/tools/hash-generator/ has a Fetch and hash button now. Give it the URL your page loads a script or stylesheet from and HeaderHawk fetches the file once and hashes exactly what that server sent, so the integrity attribute you copy matches what your visitors will receive rather than the copy on your disk. It also reads the response’s CORS headers and tells you whether a browser could check the file at all. That step most often turns a correct hash into a blocked script. Text you paste and files you choose are still hashed in your browser and are not sent anywhere.

The dashboard now opens in light or dark mode to match your operating system, and switches when your system does, instead of always starting dark. A theme you pick from the user menu is still remembered and still takes priority.

The CSP policy analyzer now gives a pasted policy the same grade the site scanner does, analyses every policy in the paste, and names allowlisted hosts known to serve JSONP endpoints or AngularJS. A share link carries the policy after the #, so it never leaves your browser, and one click takes it to the report header builder, which imports your header and applies the fixes that are safe in report-only.

Script hash reports count toward your monthly usage on every plan, but usage only showed the total. The usage card under Settings → Billing now says how many of those reports were script hashes. On the Free plan, which has no Scripts view, the sidebar shows the count where Scripts would be.

The report header builder turns the directives you choose into a Content-Security-Policy-Report-Only header with both report-uri and report-to, plus the Reporting-Endpoints header that report-to needs. It formats the result for nginx, Apache, Vercel, Netlify and Node.js, and grades it with the policy analyzer as you type.

The report header builder used to refuse 'report-sha256', the keyword that turns on script hash reporting, as if it were a typo. It now keeps it, and the policy analyzer tells you when a policy has the keyword but no report-to, or has it in a directive browsers do not read it from. The analyzer also flags any other quoted value it does not recognise, such as a misspelt 'selff'.

The hash generator gives you the 'sha256-…' value for an inline script or style, and the integrity value and full tag for a file you load from a CDN. The hashing happens in your browser, so nothing you paste is uploaded.

The policy analyzer used to say Firefox and Safari only send reports to report-uri. Safari has supported report-to since 16.4 and Firefox since 149, so its advice to keep both directives now explains that older versions of those browsers are the reason.

Violations of require-trusted-types-for and trusted-types were read as default-src with an invalid host, and all of them collapsed into a single issue. Both directives are recognised now. Their violations group by the sink or policy they name, and the explorer can filter on them.

An organization name no longer has to be unique across every HeaderHawk customer. A name another organization already had used to be refused, both at signup and on rename.

Paste a Content-Security-Policy header into the CSP policy analyzer and get graded findings, each with what to change. It runs in your browser and needs no account.

Owners and admins can now change the organization’s name from General settings. Onboarding had always said the name could be changed later; now it can.

Setting a site’s script hash sample rate to 0% still let each script hash through the first time it was seen. It now stops collection completely, first sightings included, which is what the dashboard already said it did.

Script hash reports were checked against your plan’s hard limit but never added to the monthly count, so they were missing from the usage page. Each hash report HeaderHawk records now counts as one report, and usage shows it.

Passwords are gone. Signing in is a one-time code sent to your email address, or your Google or GitHub account, so there is no password to reuse, leak or reset.

The login and signup pages now show the same form, and every address gets a code. Signing in with an unknown address used to answer that the email did not exist, which told anyone whether an address had an account. If a mistyped address creates a new, empty account, the first screen after the code says so and offers a way to sign out.

The overview’s 7-Day Trend dropped every hour that had no reports, so a week with traffic on two days drew as two bars side by side. Empty periods are now filled in, and the chart’s spacing matches the calendar.