Scanner Methodology

Public, versioned, no black-box magic.

This page documents how the VerifiedApp scanner works. We publish it because we believe a trust signal is only as trustworthy as the methodology behind it.

What we scan

• The HTML, JavaScript bundles and source maps served on the public domain.
• HTTP response headers (security headers, cookies, CORS, HSTS).
• TLS configuration via standard handshake (cipher suites, protocol version, certificate chain).
• Common „leak paths": .env, .git/, wp-config.php.bak, source maps and similar (~32 paths).

What we never do

• No login attempts, no brute-force, no credential testing.
• No exploitation — even if a vulnerability is discovered, we never attempt to abuse it.
• No POST/PUT/DELETE requests against your endpoints.
• No persistent storage of secret values in cleartext. Findings store only a hash plus a masked representation (e.g. sk_l••••••••wxyz).

Rule catalogue

Every detection rule has a stable key (e.g. SECRET-STRIPE-LIVE) and a version (e.g. 1.0). Both are recorded with every finding so reports are reproducible. The full rule catalogue with version history will be published in the public Trust Center.

Scan frequency

• Badge (€9 per 4 weeks + VAT where applicable): one scan per 4-week billing cycle (28 days) plus a one-time welcome scan right after subscription start.
• Trust (€24 per 4 weeks + VAT where applicable): daily scans plus on-demand scan trigger (rate-limited: max 5 trigger attempts per 12 hours; after 5 failures the trigger is disabled for 24 hours to prevent abuse).
• Code (€89 per 4 weeks + VAT where applicable, coming soon): daily scans plus source-code scanning via Git connect, plus encryption-hygiene rules.
• Free preview: single one-off scan with a 48-hour delay, one per domain per 90 days.

What triggers a badge revoke

Findings are graded by severity. Critical and High findings cause the badge to flip to red within 24 hours of the next scan. Medium and Low findings are reported but do not affect badge status. Info-level findings are observational only.

How to identify our scanner in your logs

We are transparent about every request we send. You can identify our traffic by:

• User-Agent header: VerifiedApp-Scanner/x.y.z (+https://verifiedapp.io/scanner-info) — every request we make carries this UA so it is easy to spot in your logs.
• Origin header on the active CORS probe: Origin: https://probe.verifiedapp.io — see below.

Active probes (Trust / Code only)

For paying customers we send one additional request per scan against the root URL of your domain to detect CORS misconfigurations:

GET / HTTP/1.1
Host: yourdomain.com
Origin: https://probe.verifiedapp.io
User-Agent: VerifiedApp-Scanner/x.y.z (+https://verifiedapp.io/scanner-info)

If your server reflects this Origin back into the Access-Control-Allow-Origin response header together with Access-Control-Allow-Credentials: true, that is a critical CORS misconfiguration that allows any website to make authenticated cross-site requests to your application. We need to send the request to discover this — looking at HTML alone cannot reveal it.

Active probes are only performed for registered customer domains (Trust or Code tier) where you have signed our Terms of Service. Badge-tier subscriptions, free preview scans, and producer-discovered URLs receive passive scanning only.

We never probe third-party infrastructure (S3 buckets, Azure Blob containers, etc.) referenced in your HTML. Even if a bucket URL is found in your code, we will never attempt to access it on your behalf — we only flag the reference itself.

Rate limiting and politeness

The scanner respects robots.txt for non-target hosts and applies per-host rate limits to avoid impact on small infrastructure. Scans are throttled and parallelised across our scanner pool.

Reporting an issue with our methodology

If you believe a scan result is wrong, or our methodology should be improved, please write to info@verifiedapp.net. We take false positives and false negatives seriously — they are the worst-case for a trust product.