Responsible Scanning Policy

This document is a working draft. It has not been reviewed by a qualified lawyer and will be before SiteGuardia operates commercially. Nothing here is legal advice.

This is the document that defines the product

Most of what SiteGuardia is can be read off this page. The free check is bounded by a set of refusals, and those refusals are not a temporary limitation of an early version. They are the reason the service can be offered to anyone without proof of ownership.

This policy is written to be read. If anything below is unclear, treat the stricter reading as the intended one and contact us.

What you agree to before a check runs

Before any request leaves our infrastructure, you confirm one thing:

I confirm I own this domain, or that its owner has expressly authorised me to have these checks run against it. I understand SiteGuardia sends automated, non-destructive requests to public resources, and that shared hosting, a CDN or a platform may be covered by a separate agreement of mine with them.

This wording changed. It used to end with "or that my use is otherwise lawful", which was an open alternative: it asked you to reach a legal conclusion about your own conduct and then accepted whatever you concluded. A confirmation that cannot be false is not a confirmation.

The second half is the part that is easy to miss. Owning your website is not the same as being able to authorise testing of everything it runs on. If your site is on shared hosting, behind a CDN or served by a platform, those are somebody else's systems answering for your name, and your own agreement with them governs what you may have tested against them.

You are responsible for that statement being true. For a site you own or operate, it is. For someone else's site, you need their agreement, and the fact that a check is non-destructive does not create permission where none exists.

What the free check does

It reads signals your site already publishes to anyone who asks for them.

• Completes TLS handshakes and reads the protocol versions, cipher suites and certificate your server offers.
• Sends a small number of ordinary GET and HEAD requests to the origin and to a bounded set of pages a crawler would reach.
• Reads public DNS records: A, AAAA, MX, TXT, CAA and DS.
• Runs OWASP ZAP in baseline mode, which crawls for a limited time and then analyses what it saw passively.
• Runs a curated, versioned allowlist of Nuclei templates, each reviewed individually.

The total request count is bounded and the whole job has a hard timeout.

What the free check never does

This list is exhaustive for the free tier and is enforced in code, not by policy alone.

• No exploitation of any finding, confirmed or suspected.
• No modification of data, no account creation, no form submission.
• No authentication of any kind, and no attempt to bypass it.
• No password guessing, credential stuffing or credential testing.
• No injection payloads: no SQL, no cross-site scripting, no command injection, no template injection, no deserialization probes.
• No fuzzing and no directory or parameter brute forcing.
• No denial of service, load testing or deliberate resource exhaustion.
• No web application firewall or CAPTCHA bypass, and no evasion techniques.
• No deliberate reading of files the site did not publish.
• No crawling of areas behind a login.
• No scanning of IP ranges, and no scanning of private, internal or loopback addresses.
• No port scanning beyond the two ports a website is served on.

Targets we refuse

Some targets are refused automatically regardless of what you attest to.

• Private, internal, loopback and link-local addresses.
• Cloud instance metadata endpoints.
• IP addresses entered directly, rather than domain names.
• Hostnames with no valid public suffix, and special-use names such as .internal, .local and .test.
• Military domains.
• Any target on our operational denylist, which we maintain in response to abuse reports and legal requests.

Government and intergovernmental domains may be placed under review depending on jurisdiction.

Limits, and why they exist

Two checks per registered domain per UTC day. There are also limits per visitor and per connection. The limits keep the service usable and make it a poor tool for mass reconnaissance, which is the main way a free scanner becomes a problem for everybody.

We may refuse, cancel or throttle any check, and we may block a target or a visitor, without notice, where we believe the service is being misused.

How we identify ourselves

Our requests carry a user agent that names SiteGuardia and links to this policy, so an operator who sees the traffic can identify it and find out what it is. We do not disguise our traffic and we do not rotate identifiers to avoid being blocked.

If you operate a site and want SiteGuardia to stop checking it, contact us and we will add it to the denylist.

What you may not do with the results

• Do not use a SiteGuardia report to attack, disrupt or gain access to a system.
• Do not use SiteGuardia to harass, intimidate or pressure anyone.
• Do not run checks against sites you have no lawful basis to assess.
• Do not automate checks at scale or attempt to circumvent the limits above.
• Do not present a SiteGuardia report as a penetration test, an audit, or a certification.

What a clean report does not mean

A result with no findings means no public signal we check failed at the time we checked. It is not evidence that a site is secure, that it has no vulnerabilities, or that it would withstand an attack. Automated checks find a subset of a subset.

Deeper checks, later

Features that require more than public observation, including scans that go beyond the boundary above, will require proof of domain ownership and, for professional work, a written scope. We will not remove this boundary for the free tier.

Reporting a problem

If SiteGuardia has caused a problem for a site you operate, or if you have found a vulnerability in SiteGuardia itself, our contact details are in our vulnerability disclosure policy and at /.well-known/security.txt. We will respond.

Changes

This policy is versioned. The version in force when a check runs is recorded with that check. Material changes will be published here with a new version and date.