Security
What AXRAY does to your site, and what it does with what it finds.
A scanner fetches URLs that strangers hand it. That is an unusual thing to run, and it deserves a page rather than a paragraph. Everything below describes behaviour that is in the code and testable, not an intention.
Against your site
We never execute anything you serve
There is no browser and no JavaScript engine anywhere in the scanner. Your HTML is read by a hand-written tokenizer that produces a tree and nothing else — no script runs, no resource is fetched because your markup asked for it, no redirect is followed automatically. That is a product decision first (it is what a crawling agent does) and a security property second: the class of attack where a scanned page runs code inside the scanner does not exist here.
One request, announced honestly
A default scan is your page plus a handful of well-known paths: /robots.txt,
/sitemap.xml, /llms.txt, /.well-known/security.txt and
/.well-known/mcp.json. Every request carries Mozilla/5.0 (compatible; AXRAY/1.0; +https://axray.online/bot) AgentExperienceScanner and a URL
explaining what we are. We do not attempt authentication, we do not submit your forms, and we do not
probe for anything.
Limits that exist to protect you, not us
- 30 requests an hour per host, counted across every AXRAY user combined, signed in or not. Your daily quota limits what you may buy; this limits what the whole service can aim at somebody.
- Repeat requests inside 10 minutes are answered from the stored result. We would rather not fetch the same page twice in a row.
- Crawls obey your
Crawl-delayand run two pages at a time, with a floor of 150 ms between requests whatever the setting says. - Scheduled checks are the same scan — monitoring runs through the same service and is bound by all of the above. It is not a second, faster path.
Turning us away takes two lines
Name AXRAY in the file you already use for this, and every scan of that host is refused from the next one onward — for everybody, not only for the person who asked, with no account and no email to us.
User-agent: AXRAY
Disallow: /
A wildcard User-agent: * rule is deliberately not treated as an opt-out, and
the reason is explained where the rule is: obeying it would make the
finding that matters most — that your robots.txt turns away every answer engine — impossible to
produce for the sites where it is true.
Against ourselves
Server-side request forgery
The target of a scan is a URL a stranger typed, so the outbound guard is the single most important
control in this system. Before any request goes out: the scheme must be http or
https, the port must be one of a short allowed list, and the hostname is resolved and
the resulting address checked — private ranges, loopback, link-local and cloud metadata addresses are
refused, and the check is applied to the address actually connected to rather than to the name, so a
DNS record that resolves inward is refused too. Redirects are followed manually and re-checked at
every hop.
The command-line tool can opt out of the address rule with --allow-private, because
scanning your own localhost:3000 before you deploy is not forgery — you already have
access to that machine. The hosted service never sets it, and cannot.
Nothing between us and the standard library
AXRAY has no runtime dependencies. Not few — none. The HTML parser, the robots.txt parser, the HTTP layer, the database, password hashing and the payment integration are all Node's own standard library. There is no third-party package in the deployed image to audit, to update, or to be compromised upstream. The build tools are the only dependencies and none of them exists at runtime.
Accounts and sessions
Passwords are hashed with scrypt from node:crypto and compared in constant time. Sessions
are opaque random identifiers in an HttpOnly, SameSite cookie, stored
server-side and revocable. Every state-changing action is a POST from a form on this origin, and the
content security policy sets form-action 'self' and frame-ancestors 'none'.
Webhooks we send
A monitoring alert is signed with HMAC-SHA256 over the timestamp joined to the raw body, using a secret
that belongs to that one monitor rather than to your account. The timestamp is inside the signed
material, so a captured body cannot be replayed later with a fresh one attached. Webhook URLs must be
https, go through the same outbound address guard as a scan target, and are not followed
through redirects. The verification code is published.
What we keep
- Scan results. The report, including the reconstruction of the page text that the report shows you. Reports are reachable only by an unguessable link and are never listed anywhere unless the domain's owner proved control and asked to be listed.
- Your account. Email address, password hash, plan, and the scans belonging to it.
- Operational records. Rate-limit counters keyed by a hash of the IP address rather than the address, and an event log of things like sign-ins and plan changes.
- Nothing from inside your site. We do not log in, so we never hold a credential of yours, and there is nothing behind your login for us to store.
The privacy policy is the authoritative version of this, and says what is done with each of them.
Reporting something
Write to hello@axray.online, or read security.txt, which is served for the same reason we grade other sites on having one. We will confirm receipt, and we would rather hear about something small than not hear about it.
What this page does not claim
There is no SOC 2 report, no ISO certification and no penetration test to hand you, and this page is not going to imply otherwise. AXRAY is a small service run transparently: the rubric is public, the scanning engine is MIT-licensed and readable, and the behaviour described above can be verified by pointing the tool at your own machine rather than by taking our word for it. If your procurement process needs a document we do not have, say so and we will tell you plainly whether we can produce it.