Security scanning

What a safe security scan should and should not do

WebWatch checks a short, fixed list of public settings and common exposures. It only scans saved sites, asks you to confirm permission, and requires proof of control before the deeper check can run.

Know what the scan will do

WebWatch offers two limited scans. Both stay on the exact website address you selected, and the report shows which requests were made. The deeper scan stays locked until you prove that you control the site.

Overview: one page request

Overview requests the site's main page once using GET /. It uses the selected HTTPS address, does not follow a redirect, and reads no more than 512 KiB.

WebWatch checks that the encrypted connection is valid, then reviews the response status, browser security settings, cookie settings, and public page code. It does not search for more pages, alter the address, submit a form, or guess filenames.

Use it for: a small first check of the site's public protections.

Verified: at most ten requests

Verified mode first checks the 1 KiB proof file again, then requests the main page. It also checks seven fixed addresses for signs of files that should not be public: /.git/HEAD, /.env, /wp-config.php.bak, /backup.sql, /server-status, /phpinfo.php, and the recognised security contact file at /.well-known/security.txt. It may make one extra OPTIONS / request without a body.

Only a small identifying part of each fixed-path response is read, up to 16 KiB, and it is then discarded. The whole scan stops after 656 KiB of response data or 45 seconds. It does not try an exploit, send a form, upload a file, sign in, guess a password, or change anything on the site.

Use it for: checking a site you control for a short list of common public exposures.

Every request a scan makes

The complete list for each mode, in the order it happens. Nothing outside these lists is ever requested.

Overview

1 request

One request to the main page, and then the scan is finished.

1
GET /
WebWatch asks the saved HTTPS address for its main page once, then reviews the reply: the encrypted connection, the response status, the browser security settings, the cookie settings, and the public page code.
- No redirect followed
- Reads at most 512 KiB
- No query string

Verified

up to 10 requests

The proof file is checked first. If it does not match your current token exactly, the scan stops there and none of the requests below are made. Only enough of each reply is read to recognise the file, and it is then discarded.

1
GET /webwatch-verify.txt
Your proof of control. The reply must be HTTP 200, use the text/plain type, and contain only the current token.
- Reads at most 1 KiB
- No redirect followed
- Scan stops here if it does not match
2
GET /
The same single main-page request that Overview makes, reviewed in the same way.
- No redirect followed
- Reads at most 512 KiB
3
GET /.git/HEAD
Looks for version-control files left in the public folder, which can expose a site's source code.
- Reads at most 16 KiB
4
GET /.env
Looks for a configuration file of the kind that usually holds database passwords and API keys.
- Reads at most 16 KiB
5
GET /wp-config.php.bak
Looks for a WordPress settings backup that anybody could download.
- Reads at most 16 KiB
6
GET /backup.sql
Looks for a database export left where the public can reach it.
- Reads at most 16 KiB
7
GET /server-status
Looks for an Apache status page that has been left open to visitors.
- Reads at most 16 KiB
8
GET /phpinfo.php
Looks for a PHP information page that lists the server setup in detail.
- Reads at most 16 KiB
9
GET /.well-known/security.txt
Looks for a published security contact file. Finding this one is a good sign, not a fault.
- Reads at most 16 KiB
10
OPTIONS /
Asks which HTTP methods the server says it will accept. No page content is requested and no reply body is read.
- No body read
- Recorded as information, not as a fault

The whole scan stops after 45 seconds, and any single request stops after 8 seconds.

Every request together may read at most 656 KiB of reply data.

Every request goes to the exact saved address. No other host, port, subdomain, or query string.

Every request identifies itself in your server logs as WebWatch Security Scanner/1.0

Permission comes before technology

Anybody can open a public website, but that does not give them permission to test it. WebWatch asks you to confirm your authority before either scan and requires a separate proof of control for verified mode.

1. Save and attest

Scans only work for sites saved to your signed-in WebWatch account. Before a scan starts, you must confirm that you own the site, manage it, or have clear permission to test it.

Important: saving an address does not prove ownership. Only scan a site when you have permission.

2. Publish the challenge

For verified mode, WebWatch gives you a random token. Publish it at /webwatch-verify.txt on the exact website address being scanned — right next to /robots.txt.

The file must contain only the token. Do not add a label, HTML, spaces, or a new line after it. It must be plain text, no larger than 1 KiB, and available without a redirect.

Why it works: placing a file at this exact address normally requires control of the site's hosting.

Permission is specific

Permission for https://example.com does not cover its hosting company, a shop on another domain, a test subdomain, a different port, or services linked from the page. WebWatch stays on the exact site address selected from My Sites.

Limits on every request

A safe scan needs clear limits. These rules stop WebWatch reaching private systems, wandering across a site, or changing data.

Internal addresses are blocked

Before connecting, WebWatch checks the site's network address. It rejects addresses for private networks, the local computer, reserved systems, and cloud service controls. It checks again when making the request and stops if the address is not safe.

Why it matters: a public-looking name cannot make WebWatch contact its own internal systems.

Hard caps, not best efforts

Each mode has a fixed number of requests, strict download limits, time limits, and no redirects. WebWatch stops a response that is too slow, too large, or outside the plan.

Why it matters: verified mode cannot grow into a scan of the whole site.

No user journeys or credentials

WebWatch does not sign in, accept passwords, press buttons, upload files, complete checkouts, submit forms, change data, or try to get around access controls. Those checks need a separate assessment with a qualified security tester.

Remember: something that was not checked has not been shown to be safe.

Reports keep summaries, not pages

WebWatch reads the limited response while the scan runs and then discards it. The saved report contains the score, requests made, finding details, a short piece of evidence, and the suggested fix. It does not keep full pages or cookie values.

Kept within WebWatch: no outside scanning service or AI receives the target, response, or report.

What the result can tell you

The score is a summary, not a safety guarantee. Read it alongside the scan mode, number of requests, findings, evidence, and confidence level.

Compare like with like

Overview and verified scans check different things. A verified scan may find more and give a lower score even when the site has not changed. Compare results only when the mode and number of completed checks are similar.

Confidence is not certainty

Even a high-confidence finding needs checking. A public filename may be harmless, a setting may be applied elsewhere, and a suggested change can break a site. Test changes safely and keep a way to undo them.

Zero findings is limited good news

It means this small set of requests did not find a problem. It does not prove that the site's code, software packages, accounts, APIs, hosting, or private areas are secure.

When to bring in a professional

Use a qualified security tester for payment systems, health or identity data, private dashboards, custom APIs, signed-in user journeys, a suspected breach, or anything where a mistake could cause serious harm. Agree the sites, dates, contacts, and emergency stop in writing before testing starts.