Skip to content
BuildThenTestedSee packages

You received a security email

A stranger emailed: they found something in your app and want to tell you about it, sometimes with a request for payment, sometimes not. Some of these are genuine researchers, some are automated scans dressed up as findings, and a few are pressure tactics. You need to tell them apart, act on the real ones, and not pay for a scan report of a public page.

Start with

Security sweep

$290

Report in 24 hours

Written for founders who built with an app builder.

What to check first, in this order

Ordered by what a stranger reaches first. Each links to a self-check you can do today and to what our test adds.

  1. 01
    Row Level Security disabled on a table

    Anyone with the project URL and the public anon key, both of which sit in the app's JavaScript, can read, edit or delete every row in the table.

    Critical
  2. 02
    Service-role key shipped in the browser bundle

    Anyone who opens the app can copy the key from the downloaded JavaScript and read, change or delete every row in every table.

    Critical
  3. 03
    Record ids accepted without an ownership check

    Anyone who changes the id in a URL or request can read, edit or delete another customer's record.

    Critical
  4. 04
    Authorization enforced only in the browser

    Anyone who calls the API directly, or edits the page in developer tools, gets the data and actions the screen was hiding.

    Critical
  5. 05
    Missing security headers

    Without these headers a browser will happily load the app inside someone else's page, over plain HTTP, or with injected scripts, which turns an otherwise small bug into a working attack.

    Medium
  6. 06
    CORS open to any origin with credentials

    Any website a signed-in user visits can call your API with that user's session and read the response, so their data leaves for a site you never approved.

    High
  7. 07
    Dependencies with known vulnerabilities

    A published advisory is a public instruction sheet, so an attacker does not need to find a flaw in your code; they only need to know which library version you run.

    High
  8. 08
    Password reset links that never expire

    An old reset email found in a shared inbox, a forwarded thread or a breached mailbox lets someone take over the account months later.

    High

What happens without checking

Genuine reports look like the one that found an inverted access check in an app with tens of thousands of user records: specific steps, a specific table or route, and a suggested fix (Taimur Khan, 2026). Vague reports that only list missing headers or a version number are usually scanner output. Reproduce the specific ones with the self-checks below before you reply.

One education app built on Lovable had 16 vulnerabilities, 6 critical; a database function denied callers whose role was 'authenticated', so anonymous callers passed and 18,697 user records were readable without login.

  • 16 Vulnerabilities found
  • 6 Critical
  • 18,697 User records exposed
  • 14,928 Unique email addresses
  • 870 Enterprise users with full PII

Feb 2026 · Taimur Khan · all sources

On the Base44 app builder, undocumented registration and one-time-password endpoints accepted a non-secret app_id, so anyone could create a verified account on a private app; Wix fixed it within 24 hours.

  • 2025-07-09 Reported to Wix
  • 2025-07-10 Fix verified
  • under 24 hours Time to fix
  • 2025-07-29 Public disclosure

Jul 2025 · Wiz Research · all sources

Which package

Security sweep

Start here

For anyone who wants the three riskiest areas checked fast.

$290

Report in 24 hours
  • API keys and secrets in the bundle
  • Row-level rules on every table
  • Cross-user data reads
  • Admin and hidden routes
  • Client-only permission checks

What you receive

Incident response check

For the day something has already gone wrong.

$790

Report in 24 hours
  • Same-day start
  • What is reachable right now
  • Containment steps in order
  • Key rotation and revocation list
  • Findings report and fixes

What you receive

Compare all packages, or run the self-check first.

Questions

is this security vulnerability email legitimate

Genuine reports give reproducible steps against a specific route, table or file and do not demand payment before details. Scanner-based emails list generic items like missing headers or an old library version and often ask for a bounty. Reproduce the specific claims with the self-checks above; thank and fix the real ones.

should i pay a bug bounty to someone who emailed me

You are not obliged to. If the finding is real and specific, a thank-you and, if you can, a modest reward keeps researchers reporting to you instead of elsewhere. Never pay for details before you have seen enough to reproduce the issue.

how do i verify a reported vulnerability

Follow the reporter's steps with a test account, with the browser's network tab open. If you cannot reproduce it, ask for a screen recording. If you can, fix it, re-test, and check whether the same shape exists elsewhere. The security sweep does this in 24 hours if you want a second pair of hands.

Other moments: before you launch, before you take payments, before an investor or security review, before a client handover, after something went wrong.