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

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 landed at an average of 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

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

What we found the most

The three most common findings across all 49 sites:

1. 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.
2. 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.
3. 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:

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:

1. Secret detection (100+ patterns: API keys, database URLs, private keys)
2. Security headers audit (CSP, HSTS, X-Frame-Options, CORS, and 8 more)
3. Cookie security (HttpOnly, Secure, SameSite flags)
4. Authentication flow analysis (unprotected endpoints, CSRF, rate limiting, IDOR)
5. CMS-specific checks (WordPress: user enum, login exposure, plugin disclosure)
6. GDPR compliance (consent, privacy policy, data deletion)
7. Dynamic testing (Nuclei templates for known misconfigurations)
8. Deep only: JavaScript deep analysis (source maps, DOM sinks, client-side auth)
9. Deep only: Infrastructure audit (TLS version, cert health, DNS email security)
10. Deep only: Supabase RLS policy validation
11. Deep only: Firebase Firestore/Storage rules audit
12. 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-coding tools, 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.

Keep it tested, not audited

None of the 5 BLOCK sites in this sample had a scanner wired into their pull-request flow. Every new feature that introduces a CORS misconfiguration or exposes an admin endpoint without auth gets caught the moment it ships, if someone set up the integration once:

• GitHub Action — one uses: line in .github/workflows/ci.yml. SARIF to Code Scanning, PR comments, configurable severity gate.
• GitLab CI template — drop-in .gitlab-ci.yml, SEKRD_API_KEY in masked variables, done.
• Live badge — /badge/by-domain/<your-site>.svg in your README flips red when verdict goes BLOCK between audits.

Scanning once is a snapshot. Scanning on every push is the guardrail.