Technical Documentation

All active scanning tools (URL Scanner, SSL Checker, Redirect Checker, SPF/DKIM/DMARC checkers, Domain Age Checker, Safe Link Checker, QR URL Scanner, Email Security Score) run on Cloudflare Workers — V8 isolates deployed to Cloudflare's global edge network, currently spanning 300+ locations in 100+ countries.

A Cloudflare Workers isolate is not a container and not a virtual machine. It is a V8 JavaScript context that executes in the same process as other isolates (separated by V8's own memory isolation) with a cold-start time of under 5 milliseconds. Each request is handled by a new isolate instance — there is no shared state between requests, no persistent heap, and no file system access. The isolate is destroyed at the end of request processing.

1. User submits URL in browser
   → HTTPS POST to https://api.incogsay.com/scan/url
   → Cloudflare routes to nearest edge PoP

2. Worker isolate spawns (no cold start overhead after warm cache)
   → Validates input format and length (max 2048 chars)
   → Extracts hostname, path, query parameters, fragment

3. Parallel analysis phase (all of these run concurrently):
   ├── DNS resolution: A, AAAA records via Cloudflare's 1.1.1.1 DoH
   ├── WHOIS/registration age: queried via edge-local RDAP endpoints
   ├── SSL certificate: TLS handshake to port 443 of resolved IP
   ├── HTTP redirect chain: HEAD requests following 301/302/307/308
   ├── Shannon entropy: calculated in-memory on hostname label
   ├── Levenshtein distance: compared against brand database (in-memory)
   ├── Homograph detection: Punycode decode + script family check
   └── Threat intelligence: queried against feed aggregator

4. Score assembly: weighted signals combined into 0–100 threat score
5. Response serialized as JSON → streamed back to browser
6. Worker isolate destroyed → no state persists

Total wall-clock time: typically 300–800ms (network-bound by slowest parallel query)

DNS queries issued by scanning workers use Cloudflare's 1.1.1.1 DNS over HTTPS (DoH) resolver. DoH encrypts the DNS query inside HTTPS, preventing network-level interception by ISPs or malicious intermediaries at the edge PoP. The resolver supports DNSSEC validation — queries for signed zones are validated against their RRSIG records before the response is used.

For email authentication checks (SPF, DKIM, DMARC, BIMI, MTA-STS), the DNS resolution order is:

1. TXT record query at the appropriate subdomain (_dmarc.domain.com, [selector]._domainkey.domain.com, default._bimi.domain.com, etc.)
2. Record parsing — the returned TXT strings are concatenated per RFC rules and parsed for the protocol-specific tag-value pairs
3. Syntax validation — each tag is validated against the RFC-defined grammar (e.g., SPF mechanism syntax per RFC 7208 §5)
4. Semantic evaluation — lookup limits are counted, include chains are followed, policy values are evaluated against valid enumerations

The privacy model for scanning tools is stateless by architecture: Worker isolates have no access to a database, no KV store writes are made for user-submitted data, and no request payload is forwarded to a logging endpoint. There is no mechanism by which a submitted URL or scan result could be retrieved after the HTTP response is sent — it does not exist anywhere on IncogSay infrastructure after the isolate terminates.

Calculator tools (age, date, time) perform all computation client-side in the browser. No data is transmitted to any server during calculator use. The only network request on a calculator page is the initial page load.

URL and link scanning tools query multiple threat intelligence sources during each scan. The selection criteria for feed inclusion are: (1) sub-200ms API response time from edge PoPs, (2) demonstrable false-positive rate below 0.5% on known-clean URLs, and (3) feed coverage of phishing domains within a 2-hour window of first detection.

The SSL Certificate Checker initiates a live TLS handshake from the Cloudflare edge to port 443 of the target hostname. The handshake uses TLS 1.3 by default with TLS 1.2 fallback. The worker parses the ServerCertificate message of the TLS handshake to extract:

• Certificate subject (CN= and O= fields from the Distinguished Name)
• Subject Alternative Names (OID 2.5.29.17) — the full SAN list including wildcard entries
• Issuer Distinguished Name (Certificate Authority identity)
• Validity window: notBefore and notAfter fields, parsed as ASN.1 UTCTime / GeneralizedTime
• Days remaining until expiry, calculated against server clock at scan time
• Certificate chain: intermediate and root CA certificates presented in the ServerCertificate record
• Negotiated TLS protocol version (TLS 1.2 / TLS 1.3)
• Negotiated cipher suite identifier

The worker does not perform a browser-equivalent certificate validation — it does not check Certificate Transparency SCTs, OCSP stapling, or the browser's CA trust store. It evaluates the raw certificate data as presented by the server.

If you identify a vulnerability in IncogSay's scanning infrastructure, API endpoints, or web application, please report it via the contact form at /contact with the subject line "Security Report." Include a description of the issue, steps to reproduce, and the potential impact. We commit to acknowledging reports within 48 hours and providing a remediation timeline within 5 business days.

Please do not submit live malware samples, perform denial-of-service testing, or access data belonging to other users. Responsible disclosure reports are reviewed on a case-by-case basis for recognition in our security changelog.