The State of SaaS Security 2026 — what 186 company scans reveal

The State of SaaS Security 2026 — what 186 company scans reveal

Over the last ninety days our platform has captured public-posture snapshots for 186 SaaS companies — Stripe, Twilio, Plaid, Atlassian, Zendesk, HubSpot, and a long tail of mid-market and niche vertical players. We didn't scan them because they were customers. We scanned them because we wanted to know what the industry actually looks like from the outside, right now, in July 2026.

We do this every quarter and publish the aggregate results because we think the SaaS security conversation is dominated by two extremes: vendor marketing that overstates the problem to sell tools, and industry reports funded by those same vendors that overstate the improvement to keep the conversation moving. Neither is useful if you're an engineering leader trying to figure out where your team stands.

This is the third year we've done this, and the picture in 2026 is genuinely mixed. TLS is a solved problem. Security headers are a persistent mess. And the gap between what you can see from the outside and what's actually broken underneath is bigger than any external scan can catch — which is the point of the last section.

The one-line headline

94% of the SaaS companies we scanned are running TLSv1.3. Only 39% have a Content-Security-Policy. Nobody has fully deployed the browser's built-in defense-in-depth stack. If your organization is above average, you have HSTS. If you're in the top 15%, you also have CSP. If you're in the top 5%, you have all six modern security response headers. That top 5% almost entirely consists of companies where a specific engineer took the time to make it happen.

What we tested and how

The snapshot is deliberately narrow. We hit the primary https://<company>.com (or .io, .co, or their equivalent) with a normal HTTP GET, recorded the response headers, checked what TLS protocol version the server negotiated, looked at whether HTTP redirects to HTTPS, and pulled the technology fingerprint from Server and X-Powered-By where present. That's it.

There's no active probing, no scraping past the landing page, no attempt to enumerate subdomains, no login attempts. Every snapshot could have been produced with curl -v and a couple of openssl s_client commands. We picked this scope precisely because it's what a search engine, a compliance auditor, or a casually motivated attacker sees when they look at your company for the first time.

We scored each company on a letter-grade scale based on how many recommended headers were present, whether HTTPS was enforced, and what version of TLS was in play. Grades roll up from a weighted score across critical (any HTTPS misconfiguration), high (missing HSTS or CSP), medium (missing X-Frame-Options, X-Content-Type-Options), and low (missing Referrer-Policy, Permissions-Policy) findings. You can see per-company snapshots and the exact rubric at https://thecybergrid.com/scan-report/<domain> — that URL works for any public domain and returns a live report.

Grade distribution

Across the 186 scanned companies:

There's a real bunching at B and B− — 65% of the industry sits there. That's not because the surface bar is punitive; the score would take three or four missing low-severity headers to fall out of the A range. It's because the average SaaS company has adopted HSTS and TLSv1.3 (the two things AWS, Cloudflare, and Vercel give you by default) and then stopped. Everything past that requires an engineer to sit down and decide to ship it.

The floor being at B− and not C or D is a genuine sign of progress. Three years ago when we started this measurement, roughly a fifth of the industry sat at C or below because they either didn't redirect HTTP to HTTPS or negotiated TLSv1.0. That whole cohort is gone. Cloud providers ate the problem for everyone.

TLS: the story of a fixed problem

The single most encouraging number in the dataset is TLS adoption:

• TLSv1.3: 94% (175 of 186)
• TLSv1.2: 4% (8 of 186)
• Older or misconfigured: 0%
• HTTPS reachable: 98% (183 of 186)
• HTTP reachable (should be zero): 0%

If you had told me in 2020 that within six years the SaaS industry would be effectively 100% on modern TLS, I would have been surprised. It turns out the combination of a browser-vendor push (Chrome deprecating TLSv1.0/1.1 in 2020), automated certificate issuance (Let's Encrypt, AWS Certificate Manager), and default-secure infrastructure providers (Cloudflare, Vercel, Netlify, Fly.io) closed the gap almost entirely.

There is a specific structural reason TLS got solved and headers didn't: TLS is a network-layer concern that infrastructure providers can fix without any application-level work from the customer. Security headers require somebody in the application code — or in an edge worker, or in a CDN rule — to make an explicit decision about what value to set. Nobody has bothered making default security headers a first-class feature of the "put this in front of your app" products.

If you're a founder building infrastructure for other developers: sensible default security headers, with an opt-out for the 5% of customers who need something exotic, would be one of the highest-leverage things you could ship in 2026. Nobody has done it well yet.

Security headers: the mixed picture

Here's where the industry has real gaps. Header adoption across our 186 scanned companies:

Two things stand out.

HSTS is doing better than we expected. 78% of the industry now sends a valid Strict-Transport-Security header with a reasonable max-age. Three years ago that was closer to 50%. The improvement is almost entirely explained by AWS Application Load Balancer and Cloudflare adding easy-to-toggle HSTS enforcement to their default configurations. Engineering leaders didn't decide to prioritize this — the infrastructure just got better at handing it to them.

CSP is stuck. Content-Security-Policy adoption sits at 39%, which is essentially where it was in our 2023 data. This is the header that actually matters most for defense-in-depth against XSS, and it's the one nobody wants to ship. The reason is straightforward: a badly configured CSP will break your production site in ways that are hard to test in staging, and rolling one out safely requires the report-only-then-enforce pattern that most teams don't have the runway to execute. If you want the full write-up on how to actually ship CSP without breaking anything, we've got it in the security headers cheat sheet for 2026 — but the short version is: start with Content-Security-Policy-Report-Only, log for two weeks, then flip.

The other headers are effectively free wins that most companies still haven't taken.

Referrer-Policy is missing on 71% of the sites we scanned. This is a two-line change (Referrer-Policy: strict-origin-when-cross-origin in your response headers) that stops your users' URLs — including any query-string tokens — from leaking to third-party sites via the Referer header. Setting it costs nothing and shipping it takes fifteen minutes.

X-Content-Type-Options: nosniff is missing on 53%. This one has literally one valid value, nosniff, and no legitimate reason to be off. It prevents browsers from MIME-sniffing responses, which is the technical basis for a category of stored-file XSS attacks. It should be on every site by default.

Permissions-Policy is missing on 88%, which is more understandable — the header is newer and the syntax is complex — but the ability to say "no third-party script on my site is allowed to request the microphone or the camera" is meaningful protection against supply-chain-style attacks through your analytics or chat vendors.

The 12% X-Powered-By problem

22 of the 186 companies (12%) still send an X-Powered-By header that discloses their backend framework. That's meaningful because it lets an attacker skip the reconnaissance phase entirely — they know your stack, so they know which specific CVEs and known bugs to try against you first.

The most common leaked technologies in our sample:

• Next.js: 11 companies
• Express: 4 companies
• WP Engine: 4 companies

None of these are dangerous by themselves. The leak is a mistake because it converts what should be a discovery step into a free hit for the attacker. Every one of these companies could remove or blank the X-Powered-By header in a five-line PR to their edge configuration.

What the surface doesn't show

We publish this report because we think external posture is a useful shorthand — but we also want to be honest about its limits, because we spend our days doing the actual pen tests that follow.

When we do a full engagement, the surface-level headers matter almost none. What matters is:

• Whether your GraphQL resolvers check authorization before hitting the database, or after
• Whether an alias-batched login mutation lets an attacker try 100 passwords per HTTP request
• Whether resetPassword throttles per email, or you can flood any customer's inbox from a single script
• Whether your admin panel's is_superuser field is protected or a staff user can promote themselves
• Whether your object IDs are enumerable, and whether the resolver leaks other tenants' data when queried
• Whether your OAuth flow validates the state parameter, and whether your JWT accepts the none algorithm

Every one of those has appeared, this year, in engagements we've run against companies whose external scan showed a solid B or better. External scans don't miss because they're bad — they miss because the interesting bugs are two or three request-response cycles below the landing page. If you want the shape of what a real engagement finds, our sample pen-test report is representative: 22 findings, 2 Critical, 6 High, and a redacted CVSS-scored write-up per finding.

We wrote about the anatomy of that gap in a longer piece on why 40% of SaaS pen tests miss the real risks. The short version: a scanner-only "pen test" that costs $500 will happily give you a green light on the exact class of bugs that any competent attacker will find in an afternoon.

The industry-specific view

We split the 186 companies into five verticals to see if patterns emerged. They did, and they matter for anyone benchmarking their own team:

Fintech and payments (Stripe, Plaid, Wise, Ramp, and 30 similar): consistently the best surface posture. 60% at A or A−, essentially universal HSTS, and CSP adoption almost double the industry average. Regulatory pressure works. When your customers ship a compliance questionnaire that asks specifically about security headers, the security headers get shipped.

Enterprise SaaS (Atlassian, Salesforce, HubSpot, and 40 similar): mid-grade with a wide spread. HSTS is nearly universal (this cohort has been prompted repeatedly by SOC 2 auditors), but CSP is under 30%. The reasoning we hear from teams in this segment is that CSP is a two-quarter engineering project and it never wins the prioritization argument against customer-facing features.

Dev tools and infrastructure (Vercel, Fly, PlanetScale, Retool, and 25 similar): surprisingly average. The stereotype is that engineer-facing companies get the details right; the data is more nuanced. HSTS is at 90%, but Referrer-Policy is at 40% and Permissions-Policy is at 20%. Our read: this segment ships fast, defaults are Cloudflare/Vercel's, and nobody has budget to slow down for the last 20% of the security-header stack.

Vertical SaaS (property management, healthcare, education, legal — 45 companies): the widest spread. This segment has the highest concentration of both A grades (a handful of teams take security very seriously because their customers are regulated) and B− grades (a lot of teams have shipped no security headers at all). Correlates strongly with company size — the SMBs in this segment tend to lag.

Consumer SaaS (Discord, Notion, Figma, and 40 similar): headers slightly better than average, but the highest rate of X-Powered-By disclosure — 22% of this cohort. Our read: this segment moves the fastest, ships the most experimental infrastructure, and hasn't cleaned up the debug headers on the way to prod.

Five recommendations

If you're an engineering leader looking at this data and wondering where to spend the next two weeks:

1. Ship Referrer-Policy tomorrow. Two lines, no risk, addresses the most-missed control in the industry. Referrer-Policy: strict-origin-when-cross-origin on every response.
2. Add X-Content-Type-Options: nosniff. Same reasoning. One line. If your framework doesn't send it by default, add it in your edge configuration.
3. Start CSP in report-only mode. Don't try to ship enforcement this quarter. Do collect two weeks of violation reports so you know what your rollout will actually break. Every hour spent in Content-Security-Policy-Report-Only mode saves you a week of production incident response later.
4. Remove any X-Powered-By header. Five-line PR to your edge or reverse proxy config. There's no legitimate reason it should be visible.
5. Run an external scan on your own site once a month. You can use our free tool — no signup — or any of the equivalents. What matters is that somebody on your team owns the number and it doesn't slip.

If you're the security lead trying to argue for headroom to do more than the surface: this report is the argument. External posture is where the industry has agreed to compete. The bugs that actually cost you a Series B live several layers below the surface, and the only way to find them is a proper penetration test with a real analyst spending three to five days in your app.

How to read this alongside other industry reports

There are other 2026 industry reports we respect. Snyk's State of Open Source Security has the best data on dependency vulnerabilities. Sucuri's Website Threat Report has the best data on active malware and compromised sites. Cloudflare's radar reports have the best data on DDoS and bot traffic patterns. This one — ours — is narrower on purpose: it's specifically about what you can see from the outside of an unauthenticated request to a SaaS company's marketing site.

Together, those four give a reasonable picture of the 2026 landscape. Ours is the one to point your board at when they ask "how do we look compared to peers"; the others are the ones to point your engineering team at when they ask "what should we prioritize next."

About CyberGrid

CyberGrid is a security-and-compliance practice for SaaS teams. We run a $1,999/year automated external assessment that continuously monitors what this report captures for a single company, ship penetration tests at a flat $4,999 (with a $1,999 retest built into the package), and offer a 90-day SOC 2 readiness program for teams that need to be audit-ready in a single quarter.

We publish this report every quarter because we think the SaaS security conversation deserves better data. If you find something that's wrong, or you want the underlying dataset for your own analysis, email us at hello@thecybergrid.com and we'll share the CSV. We're not selling the data — we're just trying to raise the floor of the conversation.

You can pull a live snapshot for your own domain at thecybergrid.com/scan-report/yourdomain.com, or you can request a free deeper scan at thecybergrid.com/free-scan if you want us to look beyond the surface.

Data captured between 2026-05-03 and 2026-07-11. 186 SaaS companies selected across five verticals, weighted toward mid-market and public-brand recognizable names. Methodology and rubric published at /methodology. This report is updated quarterly; the next edition ships in October 2026.