Site Canaries guide

Site Canaries add a small JavaScript tripwire to protected web pages. Each deployment is associated with a monitored domain and a set of recognized hostnames. Loads from those hostnames are counted as recognized activity. Loads from any other hostname are flagged for review.

This provides a direct signal when copied or proxied site content continues to execute the original Site Canary. The signal complements domain discovery and lookup enrichment by showing where protected code was observed running.

Note

Site Canaries are available as an Enterprise add-on. See the pricing page.

How Site Canaries work

1. An organization administrator creates a deployment for a monitored domain.
2. The administrator defines the exact hostnames and wildcard subdomains where the script is expected to run.
3. The generated script tag is added to the protected pages.
4. Have I Been Squatted separates recognized loads from loads observed on other hostnames.

The organization dashboard aggregates both classes of activity and correlates flagged hostnames with malicious lookup tags when that evidence exists.

Caution

A flagged load is an investigation signal, not proof that a site is malicious or a complete clone. Staging hosts, reverse proxies, cached pages, and omitted recognized hostnames can also produce flagged activity.

Create a deployment

Open Domain monitoring > Domains, select the monitored domain, then open Settings > Site Canaries.

Enter a deployment label that identifies the protected surface, such as Production homepage or Checkout, and select Create Site Canary. The console supports up to five active deployments for each monitored domain. Organization members can inspect existing configuration; an organization administrator is required to create, change, or archive a deployment.

Use separate deployments when independent labels or rotation boundaries make investigation clearer. A deployment identifier is public and is not an authentication credential.

Configure recognized hostnames

Each deployment requires at least one recognized hostname. Exact hostnames and leading wildcards are supported:

• www.example.com recognizes only that hostname.
• *.example.com recognizes subdomains below example.com, including deeper subdomains.
• A wildcard does not include the apex. Add example.com separately when the script also runs there.

The console stores up to 32 recognized hostname patterns per deployment. It removes redundant entries already covered by a broader wildcard.

Review this list after adding production hosts, content delivery hosts, preview environments, or other legitimate locations that execute the protected page. Incorrect or incomplete recognized-hostname coverage produces avoidable flagged activity.

New or updated hostname policy can take up to five minutes to propagate.

Add the embed code

Expand the deployment and copy the generated embed code. It has this form:

<script
  async
  crossorigin="anonymous"
  referrerpolicy="no-referrer"
  src="https://c.hibs.me/v1/get/{installation-id}.js">
</script>

Add the exact script tag to each protected page that should run the Site Canary. The console also provides copyable deployment prompts for assisted implementation.

Opening the script address directly returns 404 by design. Verify a deployment from a page containing the embed code.

Content Security Policy

Sites with a Content Security Policy (CSP) must allow https://c.hibs.me:

• Add the origin to script-src-elem when that directive is present.
• Otherwise, add the origin to script-src.
• With nonce-based CSP and 'strict-dynamic', add the page response nonce to the outer script tag. The loader copies the nonce to its check script.
• If require-trusted-types-for 'script' is enabled, the existing default Trusted Types policy must accept the exact https://c.hibs.me/v1/check/ prefix. The Site Canary does not create a named policy.

Keep the policy change limited to the required Have I Been Squatted origin and path. Do not allow arbitrary script addresses to accommodate the deployment.

Review activity

Open Site Canaries from the application sidebar. The organization-wide dashboard covers the last 14 days and reports:

• Total loads: All recognized and flagged Site Canary loads
• Flagged loads: Loads from hostnames outside the deployment policy
• Recognized loads: Loads from configured hostnames
• Flagged hostnames: Unique unrecognized hostnames observed in the period

The activity chart separates recognized and flagged daily volume. Flagged hostname activity ranks the unexpected hostnames and identifies the monitored domain and deployment. Malicious hostname activity shows the subset that correlates with an existing malicious lookup tag.

Hourly aggregates can lag by one to two hours. An empty recent-activity view does not immediately prove that the embed failed.

Investigate a flagged hostname

1. Confirm that the hostname is not a legitimate production, staging, proxy, or content delivery host missing from the recognized list.
2. Open the linked monitored domain and inspect the matching lookup result and enrichment.
3. Review registration, Domain Name System (DNS), web response, certificate, screenshot, and classification evidence before assigning intent.
4. Add a legitimate hostname to the recognized list, or continue through the normal tagging, alerting, and response workflow for suspicious infrastructure.

Malicious-tag correlation reflects existing lookup evidence. Site Canaries do not automatically make every flagged hostname malicious.

Archive or rotate a deployment

Archiving permanently revokes a deployment. It cannot be restored or reused. Remove its script tag from protected pages after archiving.

To rotate a deployment, archive the old deployment, create a replacement, update the site with the new embed code, and verify recognized activity after policy propagation. Historical dashboard rows can still identify an archived deployment.

Common checks

No activity appears

• Confirm the exact generated script tag is present in the rendered page markup.
• Check the browser console for CSP or Trusted Types failures.
• Verify from a page containing the embed code instead of opening the script address directly.
• Allow up to five minutes for policy propagation and one to two hours for aggregate dashboard updates.

Legitimate traffic is flagged

• Compare the observed hostname with the deployment’s recognized-hostname list.
• Add the exact hostname or an appropriately scoped leading wildcard.
• Add the apex separately when a wildcard only covers subdomains.
• Allow the updated policy to propagate before reassessing new loads.

A deployment cannot be changed

• Confirm that the signed-in user is an organization administrator.
• Confirm that the domain still belongs to the active organization.
• Archive an unused deployment if the domain already has five active deployments.

Note

For Site Canaries setup or investigation support, email ehlo@haveibeensquatted.com.