From a client domain to a report they can act on

Step one: add the domain, and prove it is yours

A domain is accepted only if it is written as a name. IP literals, localhost and internal suffixes are refused before anything is looked up, because a scanner that can be pointed at an address is a different and much worse product.

Proof of control takes one of two forms, and either is enough:

• A DNS TXT record at _glarion-verify.yourclient.com containing a 32-character token we generate for that domain.
• A file at https://yourclient.com/.well-known/glarion-verify.txt containing the same token. It is read with a five-second budget and a 4 KB ceiling; anything larger is refused rather than buffered.

Proof lasts 30 days. Not because a month is special, but because domains change hands, agencies lose clients, and a permission granted once should not outlive the relationship that granted it.

Step two: the scan, and what it is not allowed to do

Queuing a full scan is refused unless three things hold at once: the account is on a paid plan, the domain's proof of control is currently valid, and the site is under its cap of six full scans per rolling 24 hours. All three fail closed — an unreadable answer denies rather than allows.

The check is then made a second time. A job can sit in the queue while its verification lapses, and the worker is the thing that actually sends traffic, so the worker asks again before it does. Every queued scan also writes an authorisation record in the same database transaction as the job itself, so a scan cannot exist without a trail of who authorised it and when.

Intensity is capped separately from authorisation, because a verified owner can still drive enough traffic at their own host to look like an attack to their hosting provider. The scanner runs at 20 requests per second with bounded concurrency, with fuzzing, brute-force, denial-of-service and intrusive template categories excluded, with out-of-band callbacks disabled, and with a wall-clock ceiling that kills a scan rather than letting it run indefinitely. External tools are launched with an argument vector, never a shell string.

The certificate is read separately, over a real TLS handshake rather than by asking a third-party API what it thinks the certificate says.

Step three: triage, because a finding list is not a report

Running the scanner is the easy part. A real scan of a small production site returned 32 findings, of which three warranted action and nineteen were inventory — "you have an MX record", "your certificate was issued by X". Handing that list to a paying client makes the sender look careless, which is the problem this step exists to solve.

Act

Something is wrong and there is a concrete fix.

Review

Needs a human judgement call — whether it matters depends on what the site is for.

Inventory

Not a problem. Evidence of what was checked, kept for the appendix, because "we looked and it was fine" is part of what the client is paying for.

Two rules shape this. The scanner's own severity is not used as the priority: a missing Content-Security-Policy is rated informational by the tool and belongs near the top of a client report, so Glarion assigns its own ranking and keeps the original alongside it for a technical reader to reconcile. And nothing is silently discarded: inventory is demoted rather than dropped, and a finding we have not classified yet is surfaced rather than hidden, so an unfamiliar result fails toward visibility.

Step four: the report, and then the schedule

The report is a single self-contained HTML file. It carries your agency's name and logo on paid plans, makes no external requests when it is opened, and prints or saves to PDF without a separate export step. Each finding keeps its observation, the plain-English reason it matters and the suggested next step, so the person reading it can assign the work rather than forward the file.

A site can then be put on a weekly or monthly schedule. A schedule is standing authorisation, so it can only be set while control is proved, and the scheduler refuses loudly once that proof lapses rather than quietly carrying on.

Notification is sent only when a result differs from the one before it. A weekly message saying "still three issues" teaches people to filter the sender — and then the message that mattered goes unread too.

What this is not

It is not a penetration test. It is repeatable automated evidence about a defined surface at a defined time, and a clean result ages immediately: certificates approach expiry, dependencies change, new services appear. That is the argument for monitoring rather than for a single audit, and it is also the reason no scanner can certify that a website is secure.

It is not a maintenance platform either. It does not update plugins, take backups or watch uptime. Keep whatever you use for those; what that kind of tool usually calls a security check is a version comparison against a database, which finds the plugin everyone already knows about and does not find the path that answers when it should not, the certificate expiring in three weeks, or the header that was never set.

The source is public for exactly this reason. A security model you have to take on trust is worth nothing, so the gates described above can be read in the repository, along with the limitations we know about and have not solved.

Read next

• Pricing and what each plan includesFrom €19 a month, priced per account with a site allowance.
• The free public checkThe part that needs no account and no permission.
• Running Nuclei safely for clientsTemplate policy, scope and authorisation for recurring scans.
• Reports clients can act onA structure that survives being handed to a non-specialist.