Active exploitation: what Vetora proves once your domain is verified

The four checks

• TRACE method actually accepted — a real TRACE request is sent. If the server responds by echoing the request itself (behavior compliant with TRACE but dangerous if enabled), it's confirmed — not inferred from an Allow header, which could lie about what's actually implemented.
• Credentialed CORS with reflected origin — a made-up origin (never authorized anywhere) is sent in the Origin header. If the server reflects it verbatim in Access-Control-Allow-Origin with Access-Control-Allow-Credentials: true, any site can make an authenticated request (cookies included) to yours and read the response — far more serious than a plain Access-Control-Allow-Origin: *, which the passive check already detects but which browsers refuse by construction to use with credentials.
• Stripe key confirmed active — an sk_live_ or sk_test_ key found in the client JavaScript is used for a GET /v1/balance call — the endpoint Stripe itself documents as read-only, with no side effect. A successful response proves the key really authenticates against your account, not just that it looks like the right format. The account balance never appears in the report, only the masked key does. Proving you control the domain doesn't by itself prove you're authorized to use a credential a script on that domain happens to expose — a third-party CDN script or embedded widget can carry another company's Stripe key entirely — so this check also only runs with a separate, explicit opt-in checkbox, off by default.
• Unauthenticated Supabase write — a test row (empty body, no guessed columns) is inserted into every Supabase table found in the client code, using only the public anon key, then deleted immediately using the id the insert itself returned. A success proves an attacker can write arbitrary data, not just read it. Unlike the other three, this one writes to a third party's database — its cleanup isn't guaranteed the way a passive check is (PostgREST's REST interface has no cross-request transaction to roll back to if the delete fails after a successful insert), so it only runs with a separate, explicit opt-in checkbox, off by default.

Non-destructive by construction

Each of these four checks is designed to never be able to damage the scanned site, not just to try to be careful:

• TRACE is safe by definition (RFC 7231) — a compliant server just echoes the request back, there's no mutation path through this method at all.
• The CORS test is a plain GET request with a different Origin header — no data is modified.
• The Stripe check calls the endpoint Stripe explicitly documents as read-only — safe regardless of whose key it turns out to be, though it still only runs with its own opt-in since domain ownership doesn't establish authorization to use the key at all (see above).
• The row inserted into Supabase is deleted immediately (retried once if the first attempt fails), using the id the insert itself returned — never a guessed delete filter. If no id comes back in the response, the deletion is simply skipped rather than risk touching the wrong row: a single orphaned test record is a far smaller risk than a mistargeted deletion. If cleanup still fails after the retry, the report says so explicitly rather than claiming a success that didn't happen — and this specific check only runs with a separate opt-in, since it's the one check here that writes to a third party's database at all.

Deliberately excluded from this set for the opposite reason: a real PUT/DELETE request against an arbitrary path (proving you own a domain doesn't prove every endpoint is safe to modify), and AWS key verification (SigV4 requires the ID + secret pair; the associated secret has no format a passive scanner can detect).

How it gets triggered

Once your domain is verified, a dedicated button appears on the scan result page. Each scan can only trigger these checks once, and the route is limited to a small number of attempts per IP — these are real outbound requests to a third party, not a replay of already-collected data.

# Two possible methods to prove domain ownership
# (either one is enough):

# Option 1 — DNS TXT
_vetora-challenge.example.com  TXT  "vetora-verify=<token>"

# Option 2 — well-known file
https://example.com/.well-known/vetora-verification.txt