SiteCMD does not upload your source code

Desktop scan data stays on your machine

Derived scan results, issue history, scores, and project settings are stored in a local SQLite database. They do not reach a SiteCMD server unless you connect that site.

• Your source code, file paths, and file contents
• Page HTML, response bodies, and screenshots
• Scan results, scores, and issue history, unless you connect the site
• Project names, URLs, and configuration, unless you connect the site
• Core Web Vitals measurements and accessibility results, which stay in the local scan record
• Cookies, storage, or cache shared with your browser or carried over between scans
• Any new window, any download, or any top-level navigation to an internal address
• On macOS and Windows, any subresource request to a loopback, private, link-local, carrier-grade NAT, or reserved address or to a local hostname: private-network rules block those before the page loads, and the browser layer refuses to run if the rules fail to install. A scan of your own localhost dev server still loads that server's assets
• Any WebRTC or WebTransport connection: those interfaces are removed from every frame before the page's scripts run, so a page cannot open a connection around the rules
• On Linux, anything from this layer at all: the platform webview has no subresource filter yet, so web scans there skip Core Web Vitals and accessibility analysis rather than load the page with your local network reachable
• Any query to a SiteCMD-controlled or hardcoded third-party DNS service
• Scan results, page content, or anything beyond the domain name being looked up

Local scanning still makes network requests from your machine. It contacts the target and public subresources the page names, your configured DNS resolver, rdap.org for domain registration, and api.osv.dev for recognizable front-end library advisories. Those lookups do not send source files or completed scan results to SiteCMD.

• The scanned page itself, loaded in a hidden private webview to measure Core Web Vitals and, when accessibility analysis is on, run axe-core. The subresources that page then requests - images, scripts, stylesheets, fonts, fetch calls - are fetched by the platform's browser engine to the public hosts the page names, as they would be if you opened it yourself; SiteCMD does not choose them. The one request the private-network rules below cannot see is a public hostname that resolves to a private address, which is in the same position it would be in your own browser. Scheduled scans run this layer too
• The scanned site's domain name, as standard DNS queries (SPF/DMARC/DKIM/MX/DNSKEY/CAA, plus a CNAME and address lookup for the www subdomain to catch dangling aliases) to the machine's own configured DNS resolver - the same resolver every other app on the machine uses

The far side of that conversation is documented too. What the scanner requests lists every kind of request a scanned site receives, the identity SiteCMD sends, and how to block it.

Connecting a site, and what that changes

A connected site is the one feature that sends findings to a SiteCMD server. It is off until you connect one, there is no background sync, and an installation that never connects never contacts that host at all.

What travels is a finding's identity, not its source evidence: the check, its severity, the route on your site it fired on, and for a code finding a keyed hash of where it fired. Source files, raw paths, and line numbers have no field in the connected submission. The payload inspector shows the exact serialization of the snapshot it reads. A later sync rebuilds the payload from current local and connected state, so its sequence, deployment, or findings can differ.

Connected CLI commands can make the same bounded calls from a CI runner. A trusted GitHub Actions submission also requests a short-lived workload identity from GitHub's runner-provided *.actions.githubusercontent.com endpoint. SiteCMD sends that identity to the connected service with the site-scoped CI request, never with source files or raw locations.

Ownership verification is service-side. When you ask SiteCMD to verify a site, the service makes either one bounded GET to /.well-known/sitecmd-site-verification on that site or a TXT lookup for _sitecmd through cloudflare-dns.com.

Connecting a site also changes who does the scanning. A connected site can be scanned from SiteCMD's own infrastructure, on a schedule and with the app closed, and those requests leave our network rather than yours. Fixed third-party hosts used by that scan are cloudflare-dns.com for DNS, api.osv.dev for recognizable front-end library advisories, and rdap.org for domain registration expiry. A full scan can also fetch public HTTPS subresources named by the page. Every hosted request crosses the documented method, resource-type, scheme, port, and private-address policy.

What a hosted scan sends to your own site, which no capture on your machine can show you because it never crosses your wire:

• The routes you chose for the scan, fetched as ordinary GETs under the same SiteCMD identity a desktop scan sends, but from Cloudflare's network rather than from anyone's laptop. There is no fixed SiteCMD address to allowlist: the source address varies by the location that ran the scan
• A bounded set of probes about the entry route, each one a GET or a HEAD: the favicon and web app manifest the page declares, /privacy and /terms, a deliberately absent path to see how the site answers a 404, the page again with a foreign Origin header to test CORS reflection, the page again without following its redirects to trace the chain, the www variant of the hostname, a sweep of common redirect parameters on a short list of common paths to test for an open redirect, and a sample of the links the page points at, internal and external, to find the broken ones
• On a full profile, a fresh Cloudflare Browser Run context renders each route and can request public HTTPS scripts, stylesheets, images, fonts, XHR, and fetch resources from any host the page itself names. Chromium can request those resources concurrently. SiteCMD intercepts every request, fetches each bounded response through Cloudflare Workers public egress under the same URL and method policy, and fulfills it into the browser. Target hosts receive the SiteCMD identity, not Browser Run's automatic request headers. SiteCMD retains the resulting bounded browser facts, verdicts, and proxy-adjusted timing samples, not the rendered document or response bodies

And the bounds it runs under, which matter more than usual for the same reason:

• Any caller-selected scan target outside the connected, verified site's environment URL and canonical route scope. Browser subresources are page-controlled rather than caller-supplied and still have to pass the per-request public-HTTPS policy
• Response bodies, rendered DOM, or query strings into any store, log, trace, or error report: only derived verdicts and numeric timing samples survive the page step
• Any method but GET, HEAD, and the browser's own OPTIONS preflights, on your origin or any other, so that scanning your page can never become a way of operating it
• Any request over plain HTTP: the hosted address discipline refuses a non-HTTPS URL before it is fetched, which is why the check that asks whether http:// redirects is reported as unanswered from this vantage rather than graded

Operational calls, named and minimal

A small fixed set of calls keeps the app licensed and up to date and resolves your dependencies. Each sends only what it needs and is named in the table below. APIs for integrations you connect are a user-selected destination class described separately.

Analytics and crash reports, off by default

Both are opt-in and stay off until you turn them on. When enabled, they send only anonymized, sanitized diagnostics, never your scans, source, or credentials. The table below lists exactly what each one carries.

Dynamic destinations are disclosed by class

Some legitimate destinations cannot have one hostname in advance: the site and public subresources being scanned, APIs for integrations or deployment providers you connect, and public HTTPS webhook URLs you configure. Those classes are described here and in the privacy reference. They are not presented as a finite fixed-host list.