64
Mean score
63
Median score
197
Members scanned
99%
Coverage (1 failed)
Findings by severity
- Critical6
- High249
- Medium2167
- Low1192
- Info3493
Top 3 performers
| 1 | BaseFrame baseframe.co | A |
| 2 | Brumby (Formerly GrazeMate) brumby | A |
| 3 | Lexius lexius.ai | A |
64/100
Mean security score
16%
Graded B or higher
6
Critical findings across the cohort
81%
Affected by "Missing Content-Security-Policy header"
Overview
The Winter 2026 batch of Y Combinator startups – 197 companies freshly scanned for their web‑security posture – paints a picture of a community still finding its footing. While the mean security score sits at 64 / 100, the grade distribution shows that a solid majority (68 %) are clustered in the “C” band, with only a handful breaking into “A” territory. The most striking takeaway is the prevalence of missing defensive response headers: Missing Content‑Security‑Policy (CSP) headers were found on 160 of the 197 sites, indicating a systemic gap in protection against content injection attacks.
What we found
Across the cohort the severity landscape is heavily weighted toward high‑impact findings: 6 critical issues, 249 high, 2 167 medium, 1 192 low and 3 493 informational detections. The high‑severity tier dominates the narrative because these weaknesses can be directly leveraged by attackers.
Missing Content‑Security‑Policy header (high) – Detected on 160 / 197 sites (81 %). Each site lacking CSP was flagged once, for a total of 160 detections. Without CSP, browsers have no explicit whitelist of allowed resources, leaving applications open to cross‑site scripting (XSS) and data‑injection attacks.
Missing Strict‑Transport‑Security (HSTS) header (high) – Found on 38 / 197 sites (19 %). This header forces browsers to use HTTPS for all future connections. Its absence means users can be downgraded to insecure HTTP, exposing session cookies and credentials.
window.location assignment detected (high) – Present on 8 / 197 sites (4 %). Scripts that programmatically rewrite the top‑level location can be abused for open‑redirect or phishing scenarios when combined with insufficient input validation.
Form submits to external domain (high) – Observed on 5 / 197 sites (3 %), with 6 total occurrences. When a form posts data to a third‑party origin, the originating site relinquishes control over data handling and may inadvertently expose sensitive information.
Dynamic eval() usage (high) – Detected on 5 / 197 sites (3 %). The eval function executes strings as code, a common vector for code‑injection attacks if the input is not strictly sanitized.
The medium‑severity findings, while more common, are listed here only for context:
- Missing X‑Frame‑Options header on 138 / 197 sites (70 %). This omission permits click‑jacking attacks, where malicious pages embed the vulnerable site in a hidden frame.
- Dynamically injected script tags on 116 / 197 sites (59 %), detected 475 times total, indicate runtime script loading that can bypass static analysis and introduce unvetted code.
- postMessage listeners without origin checks on 107 / 197 sites (54 %), detected 130 times, expose cross‑origin communication channels to spoofed messages.
- Public JavaScript source maps on 107 / 197 sites (54 %), detected 845 times, can reveal original source code and internal comments to attackers.
- Overly permissive CORS policy (
Access-Control-Allow-Origin: *) on 101 / 197 sites (51 %). This blanket allowance lets any origin read resources, facilitating data exfiltration.
Low‑ and informational‑level findings are abundant but less actionable for immediate remediation, and therefore are not detailed here.
Who’s leading
Among the cohort, three startups stand out with top‑grade results:
- BaseFrame – Grade A
- Brumby (formerly GrazeMate) – Grade A
- Lexius – Grade A
These companies have achieved the highest composite scores, reflecting comparatively stronger security configurations across the evaluated dimensions.
What this means
The snapshot above offers a diagnostic view of the Winter 2026 Y Combinator cohort’s web‑security health. While many startups share common gaps—most notably the lack of CSP and other protective headers—there are clear pathways to improvement that can be prioritized based on severity. Companies interested in a deeper dive should request their private, detailed report, which includes specific remediation guidance, asset‑level findings, and trend analysis over time. This isn’t a punitive scorecard; it’s a collaborative benchmark to help each founder harden their product’s attack surface as they scale.
Grade distribution
A · 3
B · 29
C · 134
D · 28
F · 3
Most common issues
Ranked by severity, then by prevalence - aggregate across the cohort, never attributed to an individual company. Purely informational checks (e.g. reachability, redirect chains) are excluded.
"Sites" counts each affected company once. The total-detections figure can be higher, since a single site can trigger the same check more than once (e.g. several offending scripts on one page).
Is your company in this cohort?
This page only shows what's safe to publish. Run your own free scan to see your full report - including everything that stays private here.
Claim your reportMethodology & FAQ
What is Cohort Security?
A public, quarterly-refreshed directory of aggregate web security posture across defined groups of companies (accelerator batches, funding classes, industry verticals), built from the same free, passive scan anyone can run against any site at decloak.dev today.
What's published about a named company on this page?
Only observational posture any visitor could already determine for themselves — TLS/HTTPS configuration and security header presence — and only for this cohort's honour-roll top performers.
What about every other company in the cohort?
Every company below the honour roll is folded into the cohort-wide severity and issue-prevalence statistics only. Nothing on this page ever attributes a specific finding to an individual company outside the honour roll, or makes one identifiable by elimination.
How is this data collected?
The same free-tier scan available to anyone at decloak.dev, run once per company in the cohort. No active testing, credential access, or exploitation — see decloak.dev/scanner for exactly what the scanner does and doesn't do.
Can a company request removal from this page?
Yes, no justification required — see decloak.dev/scanner for the removal request form.
More on how this scanner works, and how to request removal →