Security Research| March 6, 2026

We Scanned 6 Startups. Every Single One Had Critical Security Flaws.

Over the past month, we performed free security assessments for 6 real startups across different industries and tech stacks. We found 47 vulnerabilities — including a fully compromised production server, exposed API keys, SSRF flaws exploitable via known CVEs, and leaked webhook tokens. Here is everything we found, how to fix it, and a checklist so it does not happen to you.

6
Startups Scanned
across 5 industries
47
Vulnerabilities Found
3 critical, 14 high
100%
Had High+ Issues
every single one
24-48h
Delivery Time
full report with fixes

TL;DR — What We Found Across 6 Startups

  • 01. 1 server was already compromised — an attacker had full access before we even started scanning
  • 02. 3 startups had secrets in frontend code — Discord webhooks, API keys, Supabase URLs visible to anyone
  • 03. 5 out of 6 were missing basic security headers — no HSTS, no CSP, no X-Frame-Options
  • 04. 1 had an SSRF via a known CVE — a patch existed for months but was never applied
  • 05. Every single startup had at least 1 high-severity issue — 100% failure rate on baseline security

Detailed Findings by Startup

CRITICALRisk Score: 9.2/10

Fully Compromised Server — Unauthorized Access Confirmed

Social Media Startup|Node.js + Custom Server

During a routine scan of a social media startup's mobile app backend, we discovered that the production server was already compromised. An attacker had gained unauthorized access, and the server's real IP was exposed behind the CDN, bypassing all DDoS protection. Directory listing was enabled, exposing source code, configuration files, and database credentials.

What We Found

  • 2 Critical: Server compromise + real IP exposure behind CDN
  • 3 High: Directory listing, WebDAV enabled, CORS misconfiguration
  • 4 Medium: Missing security headers, verbose error messages

How to Prevent This

  • Enforce strict firewall rules — only allow CDN IPs to reach origin server
  • Disable directory listing in web server config (autoindex off)
  • Implement file integrity monitoring (OSSEC, Tripwire) to detect compromise
  • Use infrastructure-as-code to rebuild servers from clean state regularly
HIGHRisk Score: 7.2/10

SSRF via Known CVE — Internal Network Exposed

EdTech SaaS Platform|Next.js + Supabase

A SaaS platform built on Next.js was vulnerable to Server-Side Request Forgery (SSRF) through CVE-2024-34351, a known vulnerability in Next.js Server Actions. This allowed attackers to make requests from the server to internal services, potentially accessing the Supabase database directly. The server's real IP was also leaked through DNS misconfiguration, and cookies lacked the Secure flag.

What We Found

  • 4 High: SSRF via CVE-2024-34351, IP exposure, insecure cookies, missing HSTS
  • 5 Medium: CSP gaps, information disclosure, missing rate limiting

How to Prevent This

  • Update Next.js immediately — CVE-2024-34351 is patched in 14.1.1+
  • Set Secure and HttpOnly flags on all cookies
  • Enable HSTS with includeSubDomains and a minimum of 1 year max-age
  • Use Cloudflare or CDN and restrict origin access to CDN IPs only
HIGHRisk Score: 7.8/10

Discord Webhook Token Exposed — Full Channel Takeover

AI Startup|React + Discord + Electron

An AI startup shipping a desktop app (Electron) and landing page had hardcoded a Discord webhook URL directly in the client-side JavaScript bundle. Anyone inspecting the code could extract the webhook token and use it to send arbitrary messages to the team's internal Discord channel — including phishing links, malware, or social engineering attacks. Additional API credentials were also found hardcoded in the Electron app bundle.

What We Found

  • 1 Critical: Discord webhook token exposed in client code
  • 1 High: Hardcoded API credentials in desktop app
  • 2 Medium: Missing CSP on landing page, outdated dependencies

How to Prevent This

  • Never hardcode secrets in frontend or Electron apps — use environment variables loaded at runtime
  • Move webhook integrations to a backend proxy endpoint
  • Use Electron's contextBridge and preload scripts to isolate sensitive logic
  • Implement secret scanning in CI/CD (GitGuardian, TruffleHog, gitleaks)
HIGHRisk Score: 5.5/10

TLS 1.0/1.1 Enabled — Vulnerable to Downgrade Attacks

E-commerce Startup|Next.js + Supabase + Stripe

An online commerce platform processing payments through Stripe still had TLS 1.0 and 1.1 enabled on their server. These deprecated protocols are vulnerable to POODLE, BEAST, and other downgrade attacks that can expose encrypted traffic — including payment data. Additionally, the Supabase project URL was disclosed in client-side code, and Content Security Policy was missing, opening the door to XSS attacks.

What We Found

  • 1 High: TLS 1.0/1.1 enabled, vulnerable to protocol downgrade
  • 4 Medium: Missing CSP, Supabase URL disclosure, X-Powered-By header, img-src gaps

How to Prevent This

  • Disable TLS 1.0 and 1.1 — only allow TLS 1.2 and 1.3
  • Configure strict Content Security Policy headers
  • Use Supabase Row Level Security and never expose the service role key
  • Remove X-Powered-By and Server headers to reduce fingerprinting
HIGHRisk Score: 6.4/10

11 Vulnerabilities in Exam Platform — API Enumeration Risk

EdTech Certification Platform|React + Vercel + REST API

A certification exam platform had 11 vulnerabilities across its web application and API layer. The REST API was susceptible to enumeration attacks — an attacker could iterate through exam IDs to access other users' exam data. Authentication endpoints lacked rate limiting, making brute-force attacks feasible. Sensitive error messages leaked internal stack traces and database structure.

What We Found

  • 3 High: API enumeration, missing rate limiting, sensitive data in errors
  • 4 Medium: CORS misconfiguration, missing security headers, verbose logging
  • 4 Low: Cookie attributes, minor header issues

How to Prevent This

  • Implement proper authorization checks on every API endpoint (not just authentication)
  • Use UUIDs instead of sequential IDs to prevent enumeration
  • Add rate limiting on authentication endpoints (max 5 attempts per minute)
  • Sanitize error responses — never expose stack traces or SQL in production
MEDIUMRisk Score: 5.8/10

Outdated WordPress Plugins with Known CVEs

Industrial Technology|WordPress + Custom Plugins

A corporate website running WordPress had multiple outdated plugins with publicly known CVEs. The admin login page was exposed at the default /wp-admin path without brute-force protection or two-factor authentication. Error pages leaked internal file paths and server configuration details, giving attackers a roadmap of the server structure.

What We Found

  • 2 High: Outdated plugins with known CVEs, exposed admin without protection
  • 3 Medium: Path disclosure in errors, missing security headers, default paths

How to Prevent This

  • Enable automatic updates for WordPress core and plugins
  • Move admin login to a custom URL and add fail2ban or Wordfence
  • Enable two-factor authentication for all admin accounts
  • Disable debug mode and verbose error pages in production (WP_DEBUG = false)

Startup Security Checklist

Based on our findings across 6 startups, here is a minimum security checklist every startup should implement before going to production. These are not advanced measures — they are baseline hygiene that 100% of the startups we scanned were missing.

Secrets Management

  • No API keys in frontend code
  • Environment variables for all secrets
  • Secret scanning in CI/CD pipeline

Server Hardening

  • TLS 1.2+ only
  • Directory listing disabled
  • Security headers (HSTS, CSP, X-Frame-Options)
  • Real IP hidden behind CDN

Authentication

  • Rate limiting on login endpoints
  • Two-factor authentication for admin
  • Secure + HttpOnly cookies
  • No sequential IDs in APIs

Dependencies

  • Automated dependency updates
  • Regular vulnerability scanning
  • Remove unused packages
  • Pin versions in production

Frequently Asked Questions

What are the most common vulnerabilities in startups?
Based on scanning 6 real startups, the most common vulnerabilities are: exposed API keys and secrets in frontend code (found in 50% of scans), missing security headers like HSTS and CSP (83%), outdated dependencies with known CVEs (33%), and misconfigured server access controls (66%). Every startup we scanned had at least one high-severity issue.
How much does a penetration test cost for a startup?
Traditional penetration testing firms charge $10,000-$50,000+ per engagement. SableOffensive offers startup-focused security scans starting at $29 for a Pre-Launch Check, $79 for a Founder Shield with OWASP Top 10 coverage, and $199 for a Scale Secure full assessment. Reports are delivered in 24-48 hours.
How long does a security scan take?
SableOffensive delivers security scan reports in 24-48 hours depending on the plan. Pre-Launch Checks are delivered within 24 hours, Pro Scans within 24-48 hours, and Full Pentests within 48 hours. Each report includes detailed findings, CVSS severity scores, and step-by-step remediation guides.
What should I do if my server is compromised?
If your server is compromised: 1) Isolate the server immediately by blocking all non-essential traffic. 2) Preserve forensic evidence before making changes. 3) Rebuild the server from a clean image — never try to "clean" a compromised server. 4) Rotate all credentials (database passwords, API keys, SSH keys). 5) Review access logs to determine the attack vector. 6) Implement monitoring (OSSEC, file integrity) to detect future compromise.

Think Your Startup Is Secure?

Every startup we scanned thought the same thing. Get a security assessment starting at $29 — before someone finds what we found.

Get Your Scan — From $29View Sample Report
Back to all research