A useful scan looks for preventable exposure without turning your monitoring account into a tool for testing somebody else's systems. Here is the exact boundary WebWatch keeps, why permission matters, and what the score can really tell you.
WebWatch does not run a mystery “deep scan”. It offers two deliberately small request plans, shows the evidence it kept, and stops at the exact HTTPS origin you selected. The deeper plan stays locked until you prove control of the site.
Overview makes exactly one direct GET / request to the site's canonical HTTPS origin. It follows no redirect and reads at most 512 KiB.
WebWatch requires a validated TLS connection, then reviews HTTP status, browser security headers, cookie flags, and public HTML configuration. It does not discover more pages, change query values, submit forms, or try hidden filenames.
Verified mode first re-checks the 1 KiB proof file, then makes the same root request. It makes signature-only reads of seven fixed paths: /.git/HEAD, /.env, /wp-config.php.bak, /backup.sql, /server-status, /phpinfo.php, and the positive disclosure check /.well-known/security.txt. It may also send one bodyless informational OPTIONS / request.
Each fixed-path response is capped at 16 KiB and discarded. The whole run stops at 656 KiB of response data or 45 seconds. There are no exploit payloads, POST requests, uploads, logins, password guesses, brute force, form submissions, or state-changing actions.
A public website is visible to everyone, but that does not mean everyone has permission to test it. WebWatch makes the person starting a scan confirm their authority, and verified checks require a second, technical proof.
Scans only work with sites already saved to your signed-in WebWatch account. Before either mode runs, you confirm that you own, administer, or have explicit permission to test that exact site.
For verified mode, WebWatch gives you a random token. Put that token at /.well-known/webwatch-verify.txt on the exact origin.
The file body must be the raw token and nothing else: no label, HTML, spaces, or trailing newline. It must be plain text, at most 1 KiB, and available without a redirect.
Permission for https://example.com does not automatically cover its hosting company, a shop on another origin, a staging subdomain, a different port, or software linked from the page. WebWatch stays on the exact origin selected from My Sites.
The useful part of a scanner is not only what it checks. It is also everything it refuses to touch.
Before connecting, WebWatch resolves the hostname and rejects private, loopback, link-local, reserved, and cloud-metadata destinations. It validates again at request time and fails closed if the destination is not safe.
Each mode has a fixed request count, strict body limits, connection timeouts, and no redirects. A slow, huge, or surprising response is stopped rather than allowed to consume open-ended resources.
WebWatch does not sign in, accept credentials, press buttons, upload files, complete checkouts, submit forms, change data, or try to bypass access controls. Authenticated and business-logic testing belongs in a separately agreed professional assessment.
Response content is inspected in memory within the documented cap and then discarded. Stored results contain the score, request coverage, finding metadata, short bounded evidence, and remediation—not page bodies or cookie values.
A tidy score is convenient, but the scope beside it is more important. Always read the mode, request count, findings, evidence, and confidence together.
An overview and a verified scan do not have the same coverage. A verified run may find more and produce a lower score even though the site did not get worse. Compare trends only when mode and coverage are similar.
High-confidence evidence is still something to verify in context. A public filename can be harmless, a header may be set elsewhere, and a recommended fix can break a site if applied blindly. Test changes safely and keep a rollback.
It means this request plan did not observe a problem. It does not prove that application code, dependencies, accounts, APIs, infrastructure, or private workflows are secure.
Use a qualified security tester for payment systems, health or identity data, privileged dashboards, custom APIs, authenticated workflows, a suspected breach, or anything where a mistake has serious consequences. Agree the written scope, dates, contacts, and emergency stop before testing begins.
Log in to WebWatch to use security scanning. Scans are private, permission-gated, and available only for sites saved to your account.
Save a site to track uptime, SEO and permission-controlled security findings over time. The free plan covers 10 sites, no card needed.