We scanned 49 of the internet's biggest sites. Here's what we found.
We pointed Sekrd at 49 real, production websites. Not toy apps. Not test environments. The actual sites you use every day: GitHub, Google, Slack, Stripe, Notion, Vercel, Replit, Toyota, BBC, Reddit.
Every site was scanned with the same engine, same rules, same scoring. No exceptions for big names. No manual overrides. Here's what the data says — and what it doesn't.
The numbers
Every single site had security findings. The cleanest (Medium, Product Hunt) still had 3. The worst had 14. The average was 9.8 findings per site.
Scores by category
| Category | Sites | Avg Score | Avg Findings | BLOCK |
|---|---|---|---|---|
| Media & Content | 5 | 89 | 7 | 0 |
| Big Tech | 5 | 85 | 9 | 0 |
| Fintech & Commerce | 5 | 84 | 10 | 0 |
| AI & Vibe Coding Tools | 5 | 82 | 11 | 0 |
| Developer Tools | 5 | 82 | 8 | 1 |
| Startup SaaS | 10 | 81 | 10 | 0 |
| Enterprise & International | 5 | 68 | 11 | 2 |
Media companies score highest. They've been doing web security for decades. Enterprise and international sites score lowest, often missing basic headers that the rest of the industry adopted years ago.
AI-built tools (Lovable, Bolt, v0, Cursor, Replit) landed at 82, right in line with the SaaS average. Not worse than hand-coded apps. Not better either.
Let's be honest about what this means
Why vibe-coded and established sites score the same
A URL scan primarily checks HTTP headers and server configuration. These are set by your hosting platform (Vercel, Netlify, Cloudflare), not by your application code. A Lovable app on Vercel gets the same headers as GitHub on Vercel. Same CSP. Same HSTS. Same score.
This doesn't mean vibe-coded apps are as secure as GitHub. It means header scanning can't tell the difference.
The real security gaps in AI-generated code live deeper:
- Source maps left in production — exposing your entire source code to anyone who checks
- Client-side auth guards with no server enforcement — bypassable with browser dev tools
- Auth tokens in localStorage — any XSS steals the session
- Exposed internal/staging URLs in production JavaScript bundles
- RLS policies that look enabled but have USING(true) — database wide open
None of these show up in a header scan. That's why we built Deep Scan — it analyzes your JavaScript bundles, tests your TLS configuration, checks your DNS email security, and (for Supabase/Firebase) validates your actual database rules.
Top 10
| # | Site | Score | Findings |
|---|---|---|---|
| 1 | medium.com | 94 | 3 |
| 2 | producthunt.com | 94 | 3 |
| 3 | github.com | 93 | 6 |
| 4 | stripe.com | 92 | 6 |
| 5 | bitbucket.org | 92 | 7 |
| 6 | substack.com | 91 | 8 |
| 7 | clerk.com | 88 | 7 |
| 8 | reddit.com | 88 | 8 |
| 9 | lovable.dev | 87 | 10 |
| 10 | hub.docker.com | 87 | 8 |
What we found the most
The three most common findings across all 49 sites:
- No Content-Security-Policy (or report-only mode) — 40+ sites. Even Google uses CSP in report-only mode, which provides zero actual XSS protection. The browsers log violations but don't block them.
- Missing security headers — Permissions-Policy, COOP, CORP. These are newer headers that most sites haven't adopted yet. Low severity individually but they add up.
- No cookie consent mechanism — GDPR compliance gap. Common on American sites that don't think about EU users.
5 sites got BLOCK. Why?
BLOCK means we found at least one critical vulnerability that creates immediate risk. Not theoretical. Practical, exploitable, today.
- CORS misconfiguration — Two sites reflected arbitrary origins with credentials. Any website can read your users' authenticated data.
- Exposed admin endpoints — API endpoints returning real data without any authentication check.
- Missing rate limiting on login — Combined with other findings, creates a brute-force attack chain.
We're not naming the BLOCK sites because we believe in responsible disclosure. Every site owner was notified via the email on file.
Free scan vs. deep scan
The data above comes from free URL scans. Here's what each tier covers:
| Check | Free | Deep |
|---|---|---|
| Security headers (CSP, HSTS, CORS) | ✓ | ✓ |
| Leaked API keys in HTML/JS | ✓ | ✓ |
| Cookie security & CSRF | ✓ | ✓ |
| WordPress / CMS checks | ✓ | ✓ |
| Source map exposure | – | ✓ |
| JS deep analysis (eval, innerHTML, client-side auth) | – | ✓ |
| TLS/certificate audit | – | ✓ |
| DNS email security (SPF, DMARC) | – | ✓ |
| Supabase RLS policy logic | – | ✓ |
| Firebase rules audit | – | ✓ |
The free scan tells you if your server is configured correctly. The deep scan tells you if your application is secure.
Methodology
Every free scan ran 7 security checks in parallel. Deep scans add 5 more:
- Secret detection (55 patterns: API keys, database URLs, private keys)
- Security headers audit (CSP, HSTS, X-Frame-Options, CORS, and 8 more)
- Cookie security (HttpOnly, Secure, SameSite flags)
- Authentication flow analysis (unprotected endpoints, CSRF, rate limiting, IDOR)
- CMS-specific checks (WordPress: user enum, login exposure, plugin disclosure)
- GDPR compliance (consent, privacy policy, data deletion)
- Dynamic testing (Nuclei templates for known misconfigurations)
- Deep only: JavaScript deep analysis (source maps, DOM sinks, client-side auth)
- Deep only: Infrastructure audit (TLS version, cert health, DNS email security)
- Deep only: Supabase RLS policy validation
- Deep only: Firebase Firestore/Storage rules audit
- Deep only: MCP server security analysis
Each finding gets a severity (critical/high/medium/low/info), a confidence level (high/medium/low), and a CWE classification for industry-standard mapping. Only high-confidence critical findings trigger a BLOCK verdict.
Scans ran from a single AWS t3.small instance in us-east-1. Average scan duration: 80 seconds.
What this means for you
If you're building with AI tools (Lovable, Bolt, Cursor, v0), your free scan score will probably look fine — around 80, same as hand-coded SaaS. That's the server config. It's the baseline.
The question is what's happening inside your app. Are your source maps exposed? Is your auth enforced server-side or just a client-side redirect? Are your Supabase RLS policies actually protecting data, or is it USING(true) everywhere?
A free scan checks the front door. A deep scan checks whether the windows are locked.
Start with a free scan to see the basics. Then run a deep scan to find what headers can't.
Don't ship until you're sekrd
Run a free scan to find the vulnerabilities your AI missed.
Scan Your App Free