How the Prodable scan works — and exactly what we can (and can't) see

The Prodable scan is a read-only security probe of your app’s public URL. It runs about 48 deterministic checks across 9 categories, grades the result from A+ to F, and shows you the full verdict with no email required. It never runs in your browser, never writes to your database, and never sees your source code — it reaches your live app from our servers exactly the way any visitor’s browser would.

Because Prodable is a paid service that actively reaches out and probes your live app, you deserve to know precisely what it does before you point it at production. This is that answer, without hand-waving: what the scan touches, what it can and can’t see, the guarantee that keeps it non-destructive, and the list of things we deliberately refuse to do. If you were about to search “is Prodable safe” or “is Prodable legit,” read this instead.

What the scan actually is

A lot of security tools run as a script inside your browser tab. Prodable is the opposite. When you enter a URL, the scan runs from our servers and makes ordinary network requests to your public address — the same requests a curious stranger, a competitor, or an automated bot would make. That inversion is the point: the scan sees your app the way the internet sees it, not the way you see it when you’re logged in as the owner.

Practically, that means we fetch your homepage and its JavaScript bundle, read the HTTP response headers, look up a handful of DNS records, and probe a small, capped set of well-known paths and API routes. We never log in. We never load service-role credentials. We can only ever observe what your deployment already hands out to anonymous traffic — which is exactly the surface an attacker gets for free.

The 9 categories and ~48 checks

Older scanners only recorded problems, so a clean site looked empty — three missing headers and nothing else. We changed the model: every check emits a result, pass or fail, grouped by category, so even a locked-down app returns a long, mostly-green report instead of a blank screen. Here is what the nine categories cover.

• ›Transport / TLS — HTTPS reachability, HTTP→HTTPS redirects, HSTS and its lifetime, certificate validity and expiry, TLS version floor, and mixed content.
• ›HTTP security headers — Content-Security-Policy strength, clickjacking protection, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, and the cross-origin isolation trio (COOP/COEP/CORP).
• ›Cookies — Secure, HttpOnly on session cookies, and SameSite strength, including a look at Supabase auth-token flags.
• ›Information disclosure — exposed .env, .git, and cloud-credential files; version banners; directory listings; leaked source maps; stray backups.
• ›DNS / email hygiene — SPF, DMARC and its policy strength, DKIM, DNSSEC, CAA, and subdomain-takeover fingerprints.
• ›Backend (Supabase / Firebase) — anonymous read and write against your tables, PostgREST schema enumeration, public storage buckets, open auth settings, and open Firebase databases.
• ›Client-side / SPA — secrets in the bundle (Stripe, OpenAI, Anthropic, Google, Slack, SendGrid, Supabase service-role keys), known-vulnerable library versions, and client-only auth smells.
• ›Config / deployment — CORS misconfiguration, open redirects, exposed CI/CD config, and default admin paths.
• ›Privacy / compliance — cookie-consent presence, third-party tracker inventory, trackers firing before consent, and PII in URLs.

The report leads with the letter grade and per-category dials, states the denominator prominently (“we ran 47 checks across 9 categories”), renders every passed check as a green row with a one-line note of what we verified, and shows evidence on every failure — the writable table, the endpoint that returned data, the masked key, the exact header value. Where it applies, findings map to OWASP and CWE identifiers.

The strictly non-destructive guarantee

Almost every check is passive — reading headers, parsing a bundle, resolving DNS. A tiny number are “active,” and each is deliberately defanged:

• ›RLS write test is a guarded empty-body insert that we distinguish from a genuine schema error. It proves whether an anonymous write is accepted without ever storing meaningful data.
• ›Open-redirect test uses a benign off-domain marker and reports only redirects we actually confirm — no payloads, no exploitation.
• ›Subdomain-takeover check is fingerprint-only. We match your dangling CNAME against a signature database and never claim or register the resource.

Path probing is capped (roughly 15 well-known paths, ~10 DNS lookups) and runs concurrently, so the scan does real work without hammering your origin. Nothing we do writes lasting data, deletes anything, or takes control of infrastructure.

Why alarmist copy can’t appear on a clean scan

The single most important design decision is that the offer branches on the highest severity actually found. This is a structural guarantee, not a promise about our marketing restraint — the alarmist branch simply doesn’t exist in the code path a clean result takes.

There are no countdown timers and no manufactured deadlines anywhere in the product. Every paid fix re-scans and shows a before/after — the structural opposite of scareware, which vanishes the moment you pay. And if the Fix doesn’t resolve the findings it scoped, you get a full refund.

What we deliberately do not do

Naming the limits is part of being trustworthy. Here is the explicit list:

• ›We don’t call it a penetration test. Sub-$3K “pentests” are usually rebranded automated scans; the label would cheapen the work and mislead you.
• ›We don’t use service-role or admin credentials, ever.
• ›We don’t store your source code from a scan. Source-level analysis is a separate, opt-in part of the Fix.
• ›We don’t log in as your users or run authenticated requests.
• ›We don’t gate the verdict. Gating “are you exposed?” is the scareware move; we gate only the fix deliverables.
• ›We don’t claim your app is “unhackable.” The badge attests that it passed our automated checks on a date — no more.

The deep kit — Semgrep static analysis on your actual source, a full git-history secret scan, and a line-by-line review of your Supabase RLS policies in SQL — runs on the Fix, where you consciously grant repo or share-link access. The free scan finds what your users could find; the Fix finds what an attacker with repo access would find. The difference is what becomes visible, not how hard we work.

Why the scan is free at all

The pain here is real and well documented. Veracode’s 2025 GenAI code-security analysis found that 45% of AI-generated code fails security tests; Wiz Research puts it at roughly 1 in 5 vibe-coded apps containing security risks; and Escape.tech’s vibe-coding study reported 2,000+ high-impact vulnerabilities and 400+ exposed secrets across 5,600 apps. Those are category statistics — they describe the population of AI-built apps, and we’ll never quote them at you as if they describe your clean app.

The free scan is our credibility engine, not our product. It’s how we find what’s worth watching. The business is the layer above the scan — continuous monitoring, a human-delivered fix when something breaks, and an independent Verified Secure badge — the things a $2 one-shot scanner structurally can’t deliver. When your scan comes back clean, that’s not a dead end; it’s the moment to lock the result in so the feature you ship next week can’t silently undo it.

FAQ