Skip to main content
UNPWNED
Back to Home

Scanning Policy

Last updated: August 15, 2026

What is UNPWNED?

UNPWNED performs owner-authorized external security testing. A scan is either initiated manually by an authorized user or created by scheduled monitoring that the user previously enabled for that domain, or requested through an approved partner API under a written authorization agreement. A no-account public check is restricted to bounded externally observable reads and never receives an official security grade. Standard scans add exposure and configuration probes only after current control of the exact target host is verified. Deep scans add further limited active probes with the additional consents described below. Standard and Deep Scans never weaponize a finding, persist access, escalate beyond the bounded confirmation described here, use discovered private credentials, intentionally collect data unrelated to documenting a security exposure, or modify anything on the target system.

How to Identify Our Scanner

Every HTTP request to a scan target includes the following product token. The default User-Agent is the complete value shown below. Owner-verified scans may use a browser-compatible User-Agent that still contains the same token. Specialized checks, including cloaking detection, may also include a crawler identifier such as Googlebot, but they do not remove the UNPWNED identity token.

UNPWNED-Scanner/1.0 (+https://www.unpwned.io/scanning-policy)
Mozilla/5.0 (compatible; UNPWNED-Scanner/1.0; +https://www.unpwned.io/scanning-policy) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36

If you see this product token in your server logs, it means an UNPWNED requester initiated a public check after making the required authorization declaration, an owner initiated a currently verified scan, monitoring previously enabled for that domain created a scan, or an approved partner used a written authorization agreement. A declaration is recorded evidence of the requester's representation, but does not independently prove control of the target. Target requests originate from UNPWNED-controlled cloud infrastructure and not from the end user's device.

Eligible owner-verified target requests are also signed with Cloudflare Web Bot Auth. The canonical Signature-Agent is "https://www.unpwned.io". Our signed Ed25519 public key directory is available at /.well-known/http-message-signatures-directory. Requests are signed again for each redirect hop that remains within the authorized target scope. Third-party service requests are not signed as the target scanner.

Bot Classification

For Cloudflare bot registration, UNPWNED applies as a Verified Bot with Intermediary access and Security Testing behavior. A public check is manually initiated and limited to passive checks. Target probes are created only after current exact-host verification, by monitoring that an authorized user previously enabled, or through an approved partner path within its permitted tier. Signed requests are limited to the verified target hostname and its authorized, in-scope subdomains. UNPWNED does not republish full page content. Scan responses are used to produce security findings, reliability telemetry, and aggregated security statistics as described in our Privacy Policy.

robots.txt and Crawl Directives

Before crawlable page and path checks, UNPWNED retrieves the applicable origin's robots.txt. Public checks honor Allow, Disallow, and Crawl-delay directives for the UNPWNED-Scanner group. Public checks fall back to the wildcard group when no scanner-specific group exists. Public scans skip disallowed paths and support crawl delays up to 60 seconds. A longer value exceeds our configured scanner safety ceiling, so the affected public checks are skipped instead of shortening it.

A manual scan with current exact domain verification and a complete authorization audit, authorized scheduled monitoring, or an approved partner scan treats retrieved crawler directives as advisory. The recorded authorization, verified hostname scope, fixed non-volumetric request limits, and non-destructive testing policy govern those scans. Advisory handling does not expand the authorized hostname scope, permit authentication, or permit destructive activity. HTTP rate-limit responses and Retry-After remain effective.

Public checks fail closed if the robots.txt request fails, returns HTTP 429 or 5xx, exceeds 512 KiB, or exceeds parser safety limits. An audited authorized scan may proceed when the policy remains unavailable after a bounded fetch attempt. An HTTP 4xx response other than 429 means the policy is unavailable and permits public crawling under RFC 9309. Bounded HTTP HEAD probes only establish whether an authorized network service is reachable. They do not crawl a page or read its content, and remain identified, rate-limited, in scope, and non-destructive.

A domain owner can use an explicit User-agent: UNPWNED-Scanner group with precise Allow, Disallow, and Crawl-delay rules to control public checks. The DNS-verified opt-out below remains the authoritative way for the domain owner to block every UNPWNED scan path and subdomain.

Request Rates and Backoff

The request scheduler caps ordinary target traffic at 8 requests per second and 12 concurrent requests. Detected Cloudflare, Vercel, and Netlify hosts start at no more than 3 requests per second and 8 concurrent requests. On owner-verified managed hosts, the first blocking or rate-limit signal reduces the profile to 1 request per second and 3 concurrent requests. Other profiles reduce to the same level after at least five recent responses contain a 30 percent or greater share of blocking signals. Valid Retry-After values on HTTP 429 and 503 responses are honored across every retry round. A value beyond the bounded scan execution window stops further target requests for that scan.

UNPWNED serializes active scans per registrable target domain so concurrent workers cannot multiply these limits against the same target.

Redirects are followed for at most five hops only while the destination remains within the authorized target scope. Every hop is revalidated against DNS and SSRF controls and signed again with Web Bot Auth when eligible. A redirect outside the authorized scope is not followed.

Firewalls and Scanner Access

Many sites run behind WAFs (Cloudflare, Vercel Firewall, Netlify Edge, AWS WAF) that challenge or rate-limit unfamiliar requests. When this happens, parts of an UNPWNED scan may not return authoritative evidence. UNPWNED marks those checks as incomplete instead of treating them as secure.

Verify ownership and re-run before changing any firewall setting. Owner-authorized scans use additional scan paths, signed request identity where eligible, bounded retries, and a reduced request cadence on managed hosts. A User-Agent or shared source IP alone is not proof that a request came from UNPWNED.

Cloudflare

Connecting Cloudflare enables zone discovery and requested SPF or DMARC fixes, but does not verify domain ownership. Ownership requires TXT, HTML file, or meta tag proof. Connecting alone does not create a firewall rule. The separate scanner-access action is available only to a paid subscriber after current verification of the exact requested hostname, confirmation that it is within an active parent Cloudflare zone visible to the connected token, activation of UNPWNED's dedicated egress proxy, and express acceptance of the current scanner-access policy. Shared cloud addresses are never eligible.

The action creates a Cloudflare IP Access Rule in Allow mode for the published dedicated UNPWNED scanner IP. Cloudflare applies this rule at the account level, so it affects every zone in the selected Cloudflare account, not only the exact requested hostname or its parent zone. For requests from that IP, Allow mode may bypass or take precedence over Bot Fight Mode, managed WAF rules, custom rules, and rate limits. Use this action only if you are authorized to make that account-wide security change.

Cloudflare API tokens remain encrypted at rest and are used only server-side. Before requesting rule creation, UNPWNED stores a durable creation intent. Its opaque identifier is included in the Cloudflare rule note solely to correlate a delayed, interrupted, or otherwise uncertain create result. When the outcome is known, UNPWNED stores the exact returned or recovered rule identifier in a durable registry. Only an exact active registry record, or a stored creation intent reconciled to the exact Cloudflare result, can establish that a rule is UNPWNED-managed. A note, description, IP match, creation intent, or audit event alone is never ownership evidence. If that exact relationship cannot be established, removal fails closed and no Cloudflare rule is deleted. The UNPWNED removal action is account-wide: it removes every UNPWNED-managed scanner access rule and revokes scanner access for every hostname bound to that Cloudflare account. Customer-created rules are not altered.

You can remove scanner access through UNPWNED or directly in Cloudflare. The active registry record remains while the rule is active. If the rule was removed directly in Cloudflare, UNPWNED uses the connected token to reconcile the exact registered rule identifier and mark the record removed. If rule creation has an uncertain outcome, the creation intent remains unresolved until UNPWNED can determine the exact result. While any active record or unresolved intent remains, Cloudflare disconnection, self-service account deletion, and administrator deletion are rejected with an HTTP 409 Conflict response. They continue only after removal and successful reconciliation.

A user whose paid plan ended or was downgraded may reconnect Cloudflare only to remove or reconcile existing scanner access. A replacement token must reach every affected Cloudflare account and each known exact rule identifier. Active registry records remain while their rules remain active, and unresolved creation intents remain until reconciled. Removed registry records, resolved creation intents, and scanner-access audit events are deleted within 24 months of their respective removal, resolution, or event timestamps. The retention job never deletes pending, unknown-outcome, or recovery-required intents. When account deletion is allowed to proceed, remaining registry and intent records linked to the account may be deleted by database cascade, while audit events may remain only until their 24-month limits expire.

UNPWNED signs eligible requests for Web Bot Auth. Cloudflare must recognize that identity before it can provide a durable access path. If a fresh owner-authorized scan still confirms a Bot Fight Mode challenge, a domain owner may briefly pause Bot Fight Mode for one manually supervised scan, then restore it immediately. This path must never be used for scheduled monitoring.

Vercel Firewall

After provider logs confirm that Vercel system protection caused the gap, the verified domain owner may manually add Vercel Firewall System Bypass only while /scanning-ips.json reports egress: dedicated and allowlist_recommended: true. Scope it to the single published dedicated IP and the exact verified domain. Shared source IPs and User-Agent values are never eligible.

System Bypass does not override your custom firewall rules, so keep them enabled. UNPWNED does not create or manage Vercel firewall rules.

AWS WAF and Other Providers

Review provider logs to confirm the WAF caused the gap. If a temporary exception is necessary, restrict it to the exact target host, request methods, and scan window, monitor it, and remove it immediately afterward. Do not create a rule that trusts a shared source IP or public User-Agent by itself.

For the provider-specific decision flow, see the scan completion guide. Cloudflare users can also open the Cloudflare scanner guide.

What Our Scans Do

A no-account public check performs a bounded passive subset covering the homepage and standardized public metadata, response headers and CSP, public DNS and certificate-transparency data, technology signals, vulnerability-disclosure metadata, and locally matched CVE signals. It does not request guessed sensitive paths, test anonymous database reads, vary Origin headers, enumerate services, or perform the other target probes listed below, and it never receives an official security grade.

After current control of the exact target host is verified, a standard UNPWNED scan may perform the following non-destructive checks against that domain:

  • SSL/TLS certificate and cipher configuration analysis
  • Security header inspection (CSP, HSTS, X-Frame-Options, etc.)
  • DNS record analysis (SPF, DKIM, DMARC, DNSSEC)
  • Checks for publicly exposed sensitive files (e.g. .env, .git/HEAD)
  • API endpoint discovery and access control verification
  • Cookie security analysis
  • CORS policy testing
  • JavaScript source analysis for exposed secrets or API keys
  • Technology stack and framework detection
  • Cloud storage bucket enumeration
  • Rate limiting verification
  • Privacy and compliance checks

Deep scans (available only for verified domain owners) additionally perform subdomain enumeration, HTTP method testing, cloaking detection, and other active techniques as described in our Terms of Service (Section 4).

Backend exposure checks may reuse only public anonymous or browser-client credentials intentionally embedded by the site, such as a Supabase anon key or Firebase browser API key, and only in their intended public client role. Private, service-role, and user credentials are never used. Row and document contents read to determine exposure are not retained in scan results.

A manually initiated Deep Scan may send four percent-encoded path traversal and local-file-inclusion requests seeking standard operating-system marker files such as /etc/passwd or win.ini. This requires current control of the exact target host plus explicit per-scan consent to the active-testing policy. A finding is recorded only when the response contains the expected marker content. The scanner does not request application files, use returned content as credentials, continue browsing the filesystem, or create, modify, or delete data. Scheduled monitoring may run this probe only when the owner separately enabled standing intrusive-probing consent for that exact monitored host.

A manually initiated Deep Scan may also perform limited SQL injection and reflected XSS detection against public HTTPS GET parameters. This requires a dedicated per-scan consent and a matching server-side policy version. These probes are excluded from public scans, partner scans, cached scans, and scheduled monitoring.

The Free plan includes two scans per month and shows the severity breakdown and all finding titles. An official score and grade require current exact-host verification and sufficient completed coverage. Re-scanning a domain that has already been scanned to confirm a fix, together with the before/after comparison between the earlier scan and the re-scan, is a paid feature and is not available on the Free plan.

What Our Scans Do NOT Do

These commitments apply to all scan traffic described on this page and submitted for Cloudflare Web Bot Auth.

  • We never weaponize a confirmed issue, persist access, or continue beyond the bounded evidence described in this policy
  • We never write, modify, or delete data on the target system
  • We never attempt to log in or bypass authentication
  • We never use discovered private credentials or intentionally collect data unrelated to documenting a security exposure
  • We never perform denial-of-service or stress testing
  • We never introduce new vulnerabilities or backdoors

Public responses are inspected only within strict byte limits. Responses are not retained as full scan archives. Reports may retain bounded excerpts, object names, and secret indicators needed to document an exposure.

On UNPWNED-owned first-party hosts only, a short-lived HMAC-signed internal identity prevents our own honeypot and scanner filters from blocking an authorized self-test. This identity is restricted in code to unpwned.io and its subdomains. It authenticates only the internal scanner transport and does not grant access to customer-facing features or private data, or apply to any third-party target.

Potential Impact on Your Systems

While our scans are non-destructive, they may have the following effects on the target system:

  • Entries in your web server access logs from our User-Agent
  • Security alerts from your WAF, IDS, or honeypot systems
  • A minor, temporary increase in network bandwidth usage
  • Automated blocking by your security infrastructure (which may block our User-Agent or IP)

These effects are comparable to what any search engine crawler or automated security assessment tool would produce when accessing publicly available resources.

User Authorization

Before a manual scan, the requester must confirm that they own the target domain or have explicit written authorization from the domain owner. When scheduled monitoring is enabled, that recorded authorization applies to each recurring scan until the monitor is disabled or deleted. Approved integration partners may use the standing authorization basis defined in their written partner agreement. Each path records its authorization source and audit data as described in our Terms and Privacy Policy.

This declaration records the requester's representation but does not independently prove authority. UNPWNED therefore restricts target probing and official grades until current control of the exact host has been verified.

UNPWNED reserves the right to request proof of authorization at any time and will suspend or terminate accounts that cannot provide satisfactory evidence.

For full legal details, see our Terms of Service (Section 3).

Opt-Out for Domain Owners

If you are the owner of a domain and want to exclude it from any future UNPWNED scanning, we offer a self-serve opt-out flow that takes about two minutes and verifies ownership via a DNS TXT record:

Self-serve opt-out

DNS-verified, instant, no email back-and-forth.

Opt Out Now →

Prefer email? You can still write to abuse@unpwned.io with the domain name(s) you want excluded and proof of ownership. We will add the domain to the exclusion list manually after review.

Once verified, every UNPWNED scan path (dashboard, public check, partner API, and recurring monitoring) will refuse to scan your domain or any of its subdomains. Any active monitoring configurations for the domain are deactivated when the opt-out is verified, and the scan worker re-checks the opt-out before executing any queued scan. The requesting user is told the domain owner has opted out.

Abuse reports. If you believe your domain was scanned without proper authorization, please contact us at abuse@unpwned.io. We take unauthorized scanning seriously and will investigate all reports. Where appropriate, we will provide the relevant consent audit records to the domain owner and may terminate the offending user's account.

Blocking Our Scanner

You can block UNPWNED scans at any time using standard web server or firewall configuration:

# Block by User-Agent (nginx example)

if ($http_user_agent ~* "UNPWNED-Scanner") {

return 403;

}

# Block by User-Agent (Apache .htaccess)

RewriteEngine On

RewriteCond %{HTTP_USER_AGENT} UNPWNED-Scanner [NC]

RewriteRule .* - [F,L]

When our scanner receives a 403 response, the scan will note the blocked status and the user will be informed that the target domain is blocking security scans.

Contact

For questions about our scanning practices, opt-out requests, or abuse reports: