Security
State of Startup Security 2026: What 408 Early-Stage Sites Reveal
October 28, 2026 · 7 min read
We ran passive, public-only checks against the websites of 408 companies from two recent Y Combinator batches. Two thirds scored a D or F, and almost every gap is a configuration setting, not a vulnerability. Here is the data, the pattern behind it, and what to fix before an investor or a first enterprise buyer runs the same checks.
Investors and first enterprise customers look at your company from the outside before they ever see your product. They run a scanner, read your DNS, and check your email setup. We wanted to know what they would find, so we ran the same kind of checks on a real cohort: the public websites of companies from the Y Combinator Summer 2026 and Fall 2026 batches. No company is named in this article, and nothing here is a list of vulnerabilities.
How we measured
Every check was passive and public. We looked at what any browser, mail server or certificate log already exposes.
- TLS: protocol versions accepted and certificate validity
- Security response headers: HSTS, Content-Security-Policy, clickjacking protection, X-Content-Type-Options, Referrer-Policy
- Email authentication: SPF, DMARC, MTA-STS and TLS-RPT
- A short list of commonly exposed files (for example .env and .git), on 91% of sites
- Public DNS records (CAA, DNSSEC, stale CNAMEs) and subdomain counts from Certificate Transparency logs
- Response headers from one homepage request, for technology fingerprints
We did not port-scan, probe subdomains over HTTP, attempt logins or send exploit traffic. Requests were paced and identified with a contact URL. Results are aggregate only; groups with fewer than 10 companies are suppressed.
Two in three score a D or F
Each site receives a score out of 100 and a letter grade. The median was 66. Only 7% reached an A or better, and the two batches were almost identical.
| Grade | All (408) | Summer 2026 (229) | Fall 2026 (179) |
|---|---|---|---|
| A+ | 2.5% | 2.6% | 2.2% |
| A | 4.7% | 6.6% | 2.2% |
| B | 10.3% | 7.9% | 13.4% |
| C | 14.5% | 15.3% | 13.4% |
| D | 49.8% | 51.5% | 47.5% |
| F | 18.4% | 16.2% | 21.2% |
Being newer or older in the programme made no visible difference. Public hygiene at this stage is set by defaults and habits, not by time since launch.
Browser protections are mostly switched off
| Gap | Companies affected | Typical fix time |
|---|---|---|
| No Content-Security-Policy | 85% | Days (report-only rollout first) |
| No clickjacking protection | 77% | 15 minutes |
| No HSTS | 67% | 15 minutes |
| No X-Content-Type-Options | 66% | 5 minutes |
| Accepts TLS 1.0 / 1.1 | 19% | About an hour |
| CSP present but allows unsafe-inline | 8% | Hours to days |
| HTTP does not redirect to HTTPS | 6% | 30 minutes |
The cheap protections are the ones that are missing. HSTS, X-Content-Type-Options and a frame rule are each absent on two thirds or more of sites, and all three together are about an hour of work. They matter because they are exactly what automated scanners and security questionnaires check first.
Email is the biggest exposure
SPF, DKIM and DMARC tell receiving servers what to do with mail that claims to come from your domain. Most startups publish the records and stop one step short of the setting that makes receivers reject forgeries.
| Gap | Companies affected |
|---|---|
| No SPF record | 9% |
| SPF present but not hard-fail (~all or ?all) | 79% |
| No DMARC record | 17% |
| DMARC in monitor-only mode (p=none) | 43% |
| No enforced DMARC (quarantine or reject) | 89% |
| No MTA-STS, among domains with mail | 98% |
| No TLS-RPT, among domains with mail | 98% |
Only 11% enforce DMARC. The 43% in monitor-only mode are watching spoofed mail be delivered. Getting to enforcement needs about two weeks of report review, so it is the one fix worth starting before it is urgent. You can check your own domain with the free email security checker.
The visible footprint is bigger than the team
Certificate Transparency logs are public records of every certificate issued. They show which hostnames a company has without touching its servers.
| Measure | Result |
|---|---|
| Companies with at least one subdomain in the public logs | 80% (median 4, top tenth 20 or more) |
| Companies with 10 or more subdomains | 24% |
| A staging, dev, admin or test-style hostname is public | 43% |
| No CAA record | 88% |
| DNSSEC signed | 9% |
| A subdomain still points at a service that no longer resolves | 4% |
A staging hostname in a public log is not a vulnerability. It is a map for anyone looking, and a reason to keep those environments behind a login. The stale-DNS figure is worth cleaning up for a different reason: a record pointing at a retired hosted service is a precondition for subdomain takeover.
The stack is uniform, so defaults decide
Early-stage companies converge on the same tools. About 43% of sites were served through Vercel, 35% through Cloudflare and 6% through CloudFront. About 40% were built on Next.js, and 92% of domains with mail use Google Workspace.
| Platform | Median score |
|---|---|
| AWS CloudFront | 79.5 |
| Cloudflare | 69 |
| Vercel | 63 |
The gap reflects which security headers each setup sends by default on a typical marketing-site configuration, not the quality of the platform. Teams that add headers explicitly score well on any of them. Fewer than 1% disclosed a web-server version, and 14% sent an X-Powered-By header, none with a version number.
What investors and enterprise buyers check
Outside-in checks are the cheap first filter in due diligence and in vendor security reviews. A failing grade does not end a deal, but it raises the next question: if the visible basics are missing, what about the controls nobody can see? That is where MFA, access reviews, device management, vendor risk and a SOC 2 report come in. See what SOC 2 costs for a sense of the effort behind that second layer.
A fix list that fits in a day
- Under 2 hours: add HSTS, X-Content-Type-Options, a frame-ancestors rule and a Referrer-Policy; redirect HTTP to HTTPS; switch SPF to hard-fail (-all); disable TLS 1.0 and 1.1; add a CAA record
- This week: publish DMARC with reporting (p=none plus an rua address); delete DNS records that point at services you no longer use; put staging and admin hostnames behind a login
- This month: move DMARC to quarantine, then reject, after two weeks of report review; roll out a Content-Security-Policy in report-only mode, then enforce it
- Before the first enterprise deal: cover the controls an outside scan cannot see
Limits of this data
- The homepage is often a marketing site on a different stack from the product, so this describes the public face, not the application
- Exposed-file probes ran on 91% of sites, and Certificate Transparency lookups succeeded for 392 of 406
- A good score shows good hygiene, not compliance, and says nothing about MFA, access control or incident response
- The data is a snapshot from 26 to 28 October 2026 and is aggregate only; no company or finding is published. CATAAM is not affiliated with or endorsed by Y Combinator
See what an outside-in check finds on your own domain
Run the free security grader →Frequently asked questions
- What percentage of startups have a weak security posture?
- In this survey of 408 early-stage startup websites, 68% graded D or F on public security hygiene, with a median score of 66 out of 100. Almost all gaps were configuration settings such as missing security headers and unenforced email authentication, not exploitable vulnerabilities.
- How many startups enforce DMARC?
- Only 11% enforced DMARC (quarantine or reject). 43% had a DMARC record in monitor-only mode (p=none), and 17% had none at all. Moving from monitor-only to enforcement typically takes about two weeks of report review.
- What do investors check in security due diligence?
- Many run an external scan covering TLS, security headers, email authentication and exposed files, then follow up with a security questionnaire covering MFA, access reviews, vendor risk and policies, and often a request for a SOC 2 report. The outside-in layer is cheap to fix before diligence starts.
- How was this startup security data collected?
- Using passive, public-only checks: TLS handshake and certificate, response headers, SPF and DMARC DNS records, a short list of commonly exposed files, public DNS and Certificate Transparency logs. There was no port scanning, no login attempts and no exploit traffic, and results are published in aggregate with no company named.