Security Testing Authorization Policy

Observing what a website publishes is not testing it. Sending it traffic designed to find a weakness is. This product draws the line there: anything a visitor’s browser would do anyway runs against any target, and anything beyond that requires you to prove control of the target first.

Two rules sit above everything else and are not configurable. Nothing here is destructive: no denial of service, no data destruction, no credential theft, no exfiltration. And nothing here exploits a third party’s system, whatever you tell it about your authorization.

These read what the target already publishes. Their traffic is indistinguishable in volume and shape from an ordinary visitor.

• Fetching the page, its headers and its cookies
• TLS handshake and certificate inspection
• Public DNS lookups, and certificate transparency log queries
• Fetching and analysing the JavaScript the site serves to everyone
• Three CORS probes carrying different Origin headers — ordinary reads, no credentials, nothing changed
• Resolving discovered subdomains, and fetching them to check for dangling records
• Requesting the OpenID Connect discovery document at /.well-known/openid-configuration — a document its specification requires to be public, and which every application fetches before it can start a login

The scanner identifies itself in its User-Agent, and never attempts to look like a browser.

These request things that may be unintentionally exposed, or send input the target did not ask for. They are refused unless the hostname belongs to an asset you have verified.

• Exposed-file probing — requesting paths like /.env and /.git/config to see whether they are served
• API documentation discovery — requesting well-known OpenAPI locations
• GraphQL introspection — a POST to an endpoint whose behaviour is not known in advance
• The AI red-team suite — adversarial prompts to a model endpoint, rate-limited to five runs an hour and capped on probes, tokens, spend and runtime
• gRPC server reflection — one HTTP/2 request asking a gRPC server to list its own services. Reflection exists so that tools can call a server without its schema files, so this asks a question the server was built to answer; nothing beyond the service list is requested, and no service is invoked. A host that is not gRPC answers with an ordinary error and is reported as not gRPC.
• Blind SSRF probing — up to twelve GET requests, each setting one URL-shaped parameter to an address on a callback host this platform operates. Nothing is written and no state is changed; the parameter is given a URL, which is the kind of value it already expects. If your server fetches that address, we record that the request arrived — the method, the time and the source address, and nothing about your response. Only runs when a callback host is configured for this deployment; otherwise the check reports that it did not run.

These are absent by decision, not by omission. Each would be straightforward to build, and each is excluded because it can harm someone who did not consent — including people who are not the target.

• HTTP request smuggling and desync testing. Confirming a desync means sending malformed requests through shared infrastructure, which can poison a cache and serve the resulting response to other people’s users. Destructive to third parties regardless of who authorised the scan.
• Exploiting any vulnerability it finds. Detection stops at evidence. The scanner never uses an injection point, never reads a file through a traversal, never proves a finding by exercising it.
• Claiming a dangling subdomain. Registering the abandoned resource is how a takeover is proven conclusively — and it is also how one is committed. Takeover findings are therefore reported as strong indications, never as confirmed.
• Credential attacks. No brute force, no password spraying, no credential stuffing, no attempt to crack a JWT signature. JWTs are decoded and read; they are never attacked.
• Load or stress testing. Requests are sequential and delayed. Nothing here tries to find a capacity limit.
• Scanning private and internal addresses. Targets resolving to loopback, RFC1918, link-local or cloud metadata addresses are refused, so the platform cannot be used to reach inside a network from the outside.

Two methods, both proving control rather than mere access:

• DNS TXT record — publish a generated token at the domain. Proves control of DNS.
• Hosted file — serve a generated token at a well-known path. Proves control of the web root.

Verification is per asset and is checked at scan time, not merely at setup. Losing control of a domain does not leave you holding a verification that outlives it.

Verification proves you control a domain. It does not establish that you are permitted to test what runs on it — those are different questions when the application belongs to a client, sits on a shared platform, or is operated under a contract that restricts testing.

You are responsible for holding that permission, for observing any testing window or exclusion your agreements impose, and for the consequences of what you scan. See the Acceptable Use Policy.

An individual scan can be cancelled while it runs. Scanning can also be halted platform-wide in a single call, without a deploy: in-flight scans finish, nothing new starts, and any red-team run in progress stops between probes. If you are unsure whether something should be running, stop it first — it costs a queued scan.