Scanning Policy

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. Standard scans inspect publicly reachable security configuration and exposure. Deep scans add limited active probes only after ownership of the target domain is verified. Standard and Deep Scans do not exploit vulnerabilities, 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.

If you see this product token in your server logs, it means an authorized UNPWNED user initiated the scan manually, previously enabled scheduled monitoring for that domain, or used an approved partner operating under a written authorization agreement. 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. Each scan is manually initiated, created by monitoring that an authorized user previously enabled, or requested through an approved partner API under a written authorization agreement. 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.

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 standard UNPWNED scan performs the following non-destructive checks against a 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 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 first scan of a domain is available on the Free plan and shows the severity breakdown and all finding titles. Score and grade are shown only when scan coverage supports a reliable result. 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 the standard and Deep Scan traffic described on this page and submitted for Cloudflare Web Bot Auth. Separately contracted Advanced Security Assessments use a specific written authorization and scope under Section 4a of our Terms and are not part of this bot submission.

• We never exploit discovered vulnerabilities
• 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.

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:

Prefer email? You can still write to [email protected] 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 [email protected]. 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:

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:

• Abuse / Opt-out: [email protected]
• General: [email protected]
• Security: [email protected]