← Back to home

Scanner Ethics

Protect Your Vibes scans third-party websites. Most of those scans run against sites the requester does not own. That single fact drives every boundary in the scanner.

Our rule: the amount of noise we put on your logs / WAF / analytics scales with the proof you've given us that you own the site. Anonymous scans are passive by default. Active probes require ownership.

The three tiers

passive — default for all anonymous / unverified scans

  • GET requests to documented public resources only:
  • The main URL
  • JS bundles referenced via <script src=…>
  • /robots.txt, /sitemap.xml, /security.txt, /.well-known/*
  • One GET per resource. Read status, headers, cookies, body.
  • DNS-over-HTTPS lookups (SPF, DMARC, DNSSEC).
  • Pure static analysis — regex over already-fetched HTML + bundle.
  • No POSTs anywhere.
  • No endpoint enumeration (no probing /api/admin, /api/users,

/.env, /.git, etc.).

  • No database / platform enumeration (no Supabase table listing,

no Firebase doc fetch, no Bubble /api/1.1/obj/*, no Base44 entity enumeration, no PocketBase collection listing, no AppWrite DB calls).

  • No GraphQL introspection.
  • No error-page injection (no /%00, no bogus paths to hunt stack

traces).

  • No redirect probing with evil.com or any other attacker-marker.

owner_verified — domain ownership proven

Unlocked after the user proves control of the target domain via one of:

  • DNS TXT record at _protectyourvibes.<domain>
  • File upload at /.well-known/protectyourvibes-verify.txt
  • HTML meta tag on the homepage

Adds to passive:

  • Endpoint enumeration (.env, .git, /api/admin, /api/users, etc.)
  • Error-page probing with suspicious paths (/%00,

/this-does-not-exist)

  • Open-redirect probing with an evil.com marker
  • GraphQL introspection POST
  • Database / platform enumeration — read-only, up to **3 sample rows

per finding** as evidence

  • Sample row fetching from accessible tables/collections (capped at 3 rows per table, 10 tables per scan, 200KB total)
  • Auth-endpoint rate-limit detection via GET / HEAD / OPTIONS

only — never a POST with fake credentials

premium_authorized — paid + owner_verified + explicit consent

Reserved for future work. Requires the paid tier AND an explicit in-app "I authorize deeper scanning" toggle on top of owner_verified.

Will unlock:

  • Live credential verification (TruffleHog-style: use a found key to

call the provider's API read endpoint and confirm it's live)

  • Playwright dynamic runtime scan
  • Privilege-escalation tests (sign up a scoped test account on the

user's own app, probe as that user)

  • Aggressive rate-limit testing with multiple rapid requests

Responsible scanning principles

These apply across all tiers.

1. Passive by default. No opt-out for anonymous callers. 2. Consent required for anything active. Ownership verification is the minimum consent bar; premium active probing requires a separate explicit toggle per scan. 3. No fake account creation. Ever. We do not POST email + password + name to /api/signup or any variant at any tier to "see what happens." Period. 4. No write probes. We do not POST to anyone's database or storage to see if writes are accepted. The old Supabase SCANNER_ENABLE_WRITE_PROBE flag has been removed from the codebase entirely. 5. No brute force. No credential stuffing, no password spraying, no account lockout induction. Rate-limit detection is done via safe HTTP verbs that don't look like an attack. 6. No injection payloads. We do not send XSS, SQLi, or command injection strings. Findings in those categories are driven by static analysis of the client bundle, not live payloads. 7. Data exfiltration is capped. When owner_verified pulls sample rows for evidence, it takes at most 3 rows per finding. We do not dump tables. 8. Transparency. Every skipped probe shows up in the results UI's "locked checks" banner so the requester can see what additional coverage ownership verification would unlock.

What's banned at every tier

These must not exist in the codebase — not gated behind a flag, not gated behind a tier, not gated behind an env var. Gone.

  • Creating real-looking user accounts on target apps
  • Any write probe to any database / storage / platform API
  • Injection payloads of any kind
  • Brute force of any kind (authentication or otherwise)

Reporting a concern

If you believe a scan against your domain violated these rules, email the project's security contact. We treat scanner-ethics reports the same as security bug reports.