Scanning policy
Sonar observes public infrastructure submitted by authenticated customers. We do not operate a global internet scanning index.
ASN routes are passive observations and do not establish authorization. A discovered range stays out of scan scope until a workspace submits written authorization and the operator reviews it. After approval, a workspace administrator can explicitly activate a range of at most 16 public addresses. Each generated IP must also pass its hosted verification challenge. Activation does not start a scan; ordinary workspace scan limits and controls still apply. Larger prefixes remain passive.
Authorization and scope
Domains require a DNS TXT verification record. Public IP addresses require a hosted HTTP verification challenge. Sonar checks the challenge before each scan. Domain ownership permits discovery within that domain; it does not establish permission to scan unrelated infrastructure or every tenant on a shared address. Customers remain responsible for the scope of their authorization.
Current scan behavior
Scans use DNS queries, public certificate-transparency lookups, TCP connection probes, HTTP requests and TLS handshakes. Port coverage is the common top-1000 TCP ports using connection (not raw) probes. For ports found open, Sonar performs low-intensity service and version fingerprinting, and on deployments with the necessary privileges it also sends single-probe UDP checks to DNS (53), NTP (123) and SNMP (161). TCP probes are padded, and on privileged deployments may be fragmented, at the packet level.
Sonar additionally performs read-only HTTP GET requests for a small fixed list of commonly misconfigured paths (for example /.env, /.git/config, server-status and phpinfo pages, robots.txt, sitemap.xml and /.well-known/security.txt) to detect accidental public exposure, fetches the site favicon for application fingerprinting, and captures a single page screenshot of a responding web surface. It enumerates subdomains from public certificate transparency, public archives and a common-name list, and resolves each candidate. No content is modified and no files are uploaded.
Optional authenticated checks are limited to exact HTTPS paths on verified assets and a customer-provided test credential. HEAD checks collect headers; explicit GET checks compare response status with and without authentication and discard the body after at most 16 KiB. Workspace administrators must confirm each GET path is read-only. GET endpoints can still have side effects if the customer misidentifies an endpoint, so these checks do not submit forms or follow redirects. The scanner does not perform password guessing, exploitation or denial-of-service testing.
One scan runs at a time across the service. Network probes are sequential, individually paced and rate-limited. Probes never use decoy addresses or spoofed sources, so all traffic originates from Sonar's own addresses. Outbound HTTP requests present standard browser User-Agent strings rather than a dedicated scanner identifier; operators who need to attribute traffic should match Sonar's source addresses and contact the address below. HTTP responses have time and size limits. Redirects are recorded rather than followed to other targets. Private, loopback, reserved and metadata addresses are excluded.
Authorized intrusive testing (opt-in)
Separately from the observation profile above, Sonar offers an opt-in tier of bounded active application checks for customers who are authorized to actively test their own assets. It is off by default and gated three ways: the operator must enable it for the deployment under written hosting-provider approval, a workspace administrator must turn it on, and each asset requires its own explicit written consent. Only an asset meeting all three conditions is actively tested.
The active checks are detection-only and non-destructive: a benign reflected-input marker (reflected XSS), a single error-trigger character (error-based SQL injection), and an external redirect marker (open redirect). They do not extract data, modify state, submit forms, perform denial-of-service or volume fuzzing, or carry out credential stuffing. Findings indicate a possible issue to confirm manually; they are not proof of exploitation. A workspace can withdraw consent or disable the tier at any time.
Customer controls
Customers can exclude individual assets, run manual scans, select a daily scan hour, disable scheduling, and cancel pending or running scans. Cancellation takes effect between bounded checks. Active jobs also stop when a workspace is suspended.
Report unexpected activity
Contact [email protected] with the target, source address, UTC timestamp and relevant request logs. Do not send credentials or unrelated personal information. The operator can suspend a workspace and stop its scans while investigating.
Hosting constraints
Scanning can be disabled globally. Deployment on a provider does not imply permission to scan; the operator must confirm applicable provider policies before enabling active observation.