What the request was
Glarion is a website security monitoring service. Somebody — very possibly you, or an agency that looks after your site — typed your domain into the free public check on our front page. That check makes exactly three HTTP requests:
GET /over HTTPS, to read the response headers.GET /robots.txt.GET /.well-known/security.txt.
It also opens one TLS connection to read your certificate's expiry date, and asks a DNS resolver for your SPF and DMARC records. DNS lookups do not touch your server at all.
The requests are GET only. Redirects are not followed. The response body is read up to a small ceiling, because the headers are what the check is for. Each request has a six-second budget and the whole check is capped at twelve, so it fails quickly rather than holding a connection open.
The public check is not a scan. It reads what your site already publishes to every visitor and every search engine crawler. Nothing is probed and no path is guessed, which is the reason it can run without anybody's permission.
What it never does
- No path discovery
- It does not request anything you have not published. There is no wordlist, no admin-path guessing and no directory enumeration.
- No vulnerability probing
- It does not try known exploit fingerprints against your site.
- No writes
GETonly. No forms are submitted and nothing is posted.- No login attempts
- No credentials are tried, ever, on any plan.
- No load
- Three requests, once, when somebody presses a button.
If it was not the public check
Glarion also runs a full vulnerability scan, and that one does request paths your site never advertised and does try known fingerprints against them. It is a different thing with a different gate in front of it.
A full scan runs only after somebody has proved control of the domain — by publishing a DNS TXT record at _glarion-verify.yourdomain or a token file at /.well-known/glarion-verify.txt — and that proof expires after 30 days and is checked again at the moment the scan runs. If you did not create either of those and nobody with access to your DNS did, no full scan of your domain has happened.
The full scan is performed by a separate scanner process which sends its own default User-Agent rather than Glarion/1.0, so a scan is not identifiable by that header. It runs at 20 requests per second with bounded concurrency, and with the fuzzing, brute-force, denial-of-service and intrusive template categories excluded. A domain is capped at six full scans per rolling 24 hours.
A request for /.well-known/glarion-verify.txt carrying Glarion/1.0 is somebody attempting to prove control of your domain. If that was not you or your agency, it failed — the file has to exist and contain a token we generated — but it is worth knowing about.
How to stop it
The check is an ordinary HTTPS client. Refuse it and it fails; there is no retry loop and no second address it comes from instead.
- Block or rate-limit the User-Agent
Glarion/1.0at your web server, CDN or WAF. - Or return anything that is not a success for those three paths. The check reports what it could not read rather than inventing a result.
Adding a Disallow to robots.txt will not stop it, and we would rather say so than imply otherwise. The public check is a user-initiated request for three specific published files, not a crawl, and it does not consult robots.txt before reading the file it is checking for the existence of. If you want it refused, refuse it at the server.
If you think something went wrong
If a Glarion request caused a problem on your site, or you believe a scan ran against a domain nobody authorised, we want to hear about it directly rather than read about it later. The contact address is published at /.well-known/security.txt and the disclosure policy is in SECURITY.md.
The service's source is public, so the behaviour described on this page can be checked rather than believed: the public check is crates/orchestrator/src/preview.rs and the scan policy is crates/orchestrator/src/policy.rs.