This week we ran our biggest scan yet. 6,194 web apps queued, 5,850 successfully fingerprinted, 1,630 with at least one CRITICAL or HIGH finding. 159 had a CRITICAL. 1,471 had a HIGH but no CRITICAL. The rest had only MEDIUMs or were clean.
The vulnerability mix was not surprising. Open admin panels, login endpoints with no rate limiting, Supabase tables with row-level security disabled, payment webhooks that accept unsigned events, hardcoded API keys baked into the JS bundle. The same playbook that has been broken for a decade.
That is not the story. The story is what happened when we tried to email all 1,630.
The findings, briefly
Most of the HIGH severity total comes from auth issues. 3,162 of our 5,094 CRITICAL+HIGH findings live in the auth bucket. Some patterns from the batch:
- 1,646 login endpoints with no rate limiting. /login, /api/login, /auth/login, /api/auth/signin. We send 10 POSTs in 200ms. Status codes are all 401, no slow-down, no captcha, no lockout. Try a million passwords.
- 1,398 admin panels reachable without auth. /admin, /admin/dashboard, /panel, /internal, /wp-admin, /phpmyadmin, /_admin. Public to anyone who guesses the path.
- 252 Supabase databases with broken row-level security. Anonymous reads or writes on tables holding user data. We have written about this one before.
- 130 webhook endpoints that accept fake payment events. POST a checkout.session.completed without the signature header, get a 200 back. We blogged about that one yesterday.
- 55 API keys hardcoded in JS bundles. View source, grep for "key=" or "Bearer ". Use the key. Rate limit hits the company's bill, not yours.
- 184 endpoints leaking version, debug, or stack-trace info. /redoc, /swagger-ui.html, /api/debug/, verbose error pages.
None of this is novel. Every line above is the same finding we file at every customer. The reason we keep filing it is that no one is fixing it at the population level.
Trying to tell anyone
Standard responsible disclosure: find a contact, email them with the finding, give them 90 days. We use a multi-stage pipeline because we have 1,630 apps to work through, not 1.
Stage 1: existing pool. We had emails on file for 185 of the 1,630 affected hosts from prior scans. 11.4%.
Stage 2: Apollo. For the 1,012 unenriched custom domains, we tried Apollo's people-search API. Apollo claims 100M+ professionals indexed. They returned exactly zero contacts for any of the 351 domains we queried (351 because the rest had findings but were on platform subdomains where org-domain enrichment does not apply). These apps are too small or too new to appear in any sales database.
Stage 3: scrape the app itself. We pulled the homepage, /about, /contact, /imprint, /privacy, /team, /humans.txt for each of the 661 platform-subdomain hosts. Looked for mailto: links, footer text, and email patterns inside the JS bundle. 124 hits, about 19% of platform-subdomain apps embed an author email somewhere on the page. The other 81% don't.
Stage 4: DNS and registrar lookups. For the 351 unenriched custom domains, we tried DNS SOA rname (the responsible-person email in the DNS authoritative record), WHOIS Registrant Email, /.well-known/security.txt, and /humans.txt. 33 total hits. Most WHOIS records are GDPR-redacted. Most DNS SOA rname fields point at the cloud provider ([email protected], [email protected]), not the developer. Most apps don't ship a security.txt.
Stage 5: GitHub profile. Some apps link to a github.com/<user> URL in the footer. We pulled the user's public profile and checked for a public email. 4 hits, of 50 GitHub API calls (we capped to stay under unauth rate limits).
Final tally for this batch: 326 newly-found contacts plus the 185 we already had plus 264 we had emailed in earlier rounds equals 775 reachable affected hosts. The other 855 have no working channel. 695 are platform subdomains. 160 are custom domains where every channel returned nothing.
The platform-subdomain problem
Of the 855 we cannot contact, 695 are deployed on multi-tenant hosting platforms. The breakdown is illuminating:
| Platform | Affected hosts |
|---|---|
| lovable.app | 142 |
| streamlit.app | 119 |
| onrender.com | 93 |
| replit.app | 74 |
| herokuapp.com | 57 |
| azurewebsites.net | 51 |
| railway.app | 49 |
| vercel.app | 43 |
| netlify.app | 41 |
| firebaseapp.com | 38 |
| fly.dev | 34 |
| appspot.com | 25 |
| bolt.host | 19 |
| deno.dev | 8 |
| workers.dev | 5 |
Each of these platforms gives developers a free or low-friction way to ship an app. That is great. None of them gives a security researcher a route to the app's owner. There is no /.well-known/contact, no per-app security email, no "report a security issue" link in the platform-supplied footer, no way to ask the platform to forward a message to the developer. The platforms have a security@ for issues with the platform itself, but not for issues with apps running on top of it.
The result: a developer can ship an app on Lovable or Streamlit or Replit, expose 17 critical Supabase RLS misconfigurations to the public internet, and we have no way to tell them. Their users are at risk. The developer often does not know it. The platform sees the traffic but does not act because the platform's terms-of-service does not put them in the loop on individual app vulnerabilities.
What should change
Hosting platforms should add a per-app security contact channel. The bar is low.
Minimum: when a security researcher visits https://<app>.lovable.app/.well-known/security-contact, the platform returns a tokenized email address that forwards to whichever account deployed the app. The token can rotate. The address can rate-limit. The app owner can opt out. None of that requires the platform to expose the developer's identity. It just requires that messages to that address get to the right human.
Better: the platform's deploy UI prompts new users for a security contact email at sign-up, and the platform serves a generated security.txt at the app's apex with that email. Most platforms already prompt for billing email and notification email. One more field.
Best: the platform runs its own automated scan against new deploys and surfaces findings in the developer's dashboard before anyone else can find them. We would be out of a job for that segment, which is fine.
Until something like this exists, half of the security issues we find on hosted-platform apps are going to stay shipped. We will keep scanning, we will keep enriching, we will keep emailing the ones we can. For the 855 we cannot reach this round, we are open to suggestions.
Notes on method
The 5,850 figure is targets that completed at least one full scan run. The other 344 in the input list either failed DNS, refused all requests, or 5xx'd through the entire scan window. Our affected count of 1,630 is unique hosts with at least one finding in CRITICAL or HIGH after a 16-module sweep that includes auth-bypass, supabase-audit, payment-bypass, openapi-audit, secret-scan, login-bruteforce, admin-panel, and the rest.
If you are running an app on one of the platforms above and you are wondering whether your app is in the unreachable 855, run the scanner: securityscanner.dev. It is free for the first scan. If you want a contact channel set up for your platform, email [email protected].