If you see a shield icon to the right of the site title and click on it, you’ll see a pop-up modal indicating that this site scored an A+ on Qualys SSL Labs, Security Headers, and Mozilla HTTP Observatory. Click on one of the links in that modal, and you can verify the test yourself. This is something I add to all my new projects.
Could the scores be better? Yes, actually. There are still things that continued tweaking could improve. But you know who’s not getting these scores? Mainstream brands and large organizations—even in sectors where security is paramount.
The Scorecard
I ran the same three tests against a handful of major sites on January 25, 2026:
| Company | Site | SSL Labs | Security Headers | Mozilla Observatory |
|---|---|---|---|---|
| Chase Bank | www.chase.com | A+ | A | B |
| Chase Bank (login) | secure.chase.com | A+ | F | C+ |
| UnitedHealthcare | www.uhc.com | A | D | F |
| Mount Sinai Health System | www.mountsinai.org | A+ | F | F |
| Walmart | www.walmart.com | A+ | B | D+ |
| General Motors | www.gm.com | A | D | F |
Chase’s main site does reasonably well—A+ on SSL, A on headers—but their secure subdomain, where you actually log in, gets an F on Security Headers and a C+ on Mozilla’s test. A major financial institution.
UnitedHealthcare, one of the largest health insurers in the country, scores an F on Mozilla HTTP Observatory. Mount Sinai, a major healthcare system, fails two of the three tests. Walmart and GM don’t fare much better.
Is Front-End Security Everything?
Far from it. These tests evaluate TLS configuration, HTTP security headers, and general web hygiene—they don’t see what’s happening on the backend. A site could ace all three tests and still have SQL injection vulnerabilities or misconfigured IAM policies.
But these scores do reveal something: the visible, measurable aspects of web security that any organization could get right with minimal effort are often neglected. These aren’t exotic attacks—they’re baseline configurations that have been standard practice for years.
What Good Looks Like
For comparison, here’s what a small project can achieve with some attention to detail.
I recently built a call transcription portal on top of AWS services, including AWS Transcribe. It handles protected health information and runs under a signed Business Associate Agreement with AWS. Here’s what went into the security posture:
Transport Security:
- TLS 1.2+ with strong cipher suites (A+ on SSL Labs)
- HSTS with preload, one-year max-age
- Automatic upgrade of insecure requests
Security Headers:
- Content Security Policy with
default-src 'none'—deny by default - X-Frame-Options: DENY (prevents clickjacking)
- X-Content-Type-Options: nosniff
- Strict Referrer-Policy
- Permissions-Policy disabling unused browser features
Authentication:
- AWS Cognito with mandatory MFA (TOTP)
- 12-character minimum passwords with complexity requirements
- Account lockout after 5 failed attempts
- JWT-based API authentication
Email Security:
- SPF with hard fail
- DKIM with proper alignment
- DMARC set to reject, with strict alignment
Data Protection:
- Zero-retention policy for PHI—audio and transcripts deleted immediately after processing
- Lifecycle policies as a safety net
- Encryption at rest (AES-256) and in transit
- CloudWatch logging with 7-day retention
The result: A+ across all three tests, 10/10 on CSP analysis, and a 125/100 on Mozilla Observatory (they award bonus points for going beyond the baseline).
This isn’t because I’m a security expert. It’s because I cared enough to configure it properly and had the time to iterate until the tests passed.
Why Homegrown Sometimes Wins
UnitedHealthcare’s website runs on CloudFront—the same infrastructure this site uses. They could achieve the same scores. So why don’t they?
I have a theory: when you’re a large organization buying enterprise software or working with major vendors, security configuration often falls into the cracks between responsibilities. The vendor may handle the application layer, your infrastructure team handles networking, and your security team reviews policies—but nobody owns the HTTP headers that go out with every response.
Internal teams building homegrown solutions sometimes go the extra mile because they own the whole stack. There’s no vendor to blame, no contract to renegotiate, no support ticket to open. If something is wrong, they just fix it.
I’m not suggesting vendors are bad. I’ve worked with plenty of excellent ones over the years. But they don’t always have the same incentives as a determined internal team that will be supporting the same users day after day, year after year.
A Pattern I’ve Seen Before
This reminds me of something I’ve observed repeatedly throughout my career. When my employer ran a commercial application for several years, my team and I started to know things about that version of the software that the application vendor’s own support staff typically didn’t know.
I’ve seen this play out not just once or twice, but many times. The vendor’s support team fields questions from thousands of customers across several versions. We were supporting a specific population of users, on a specific version, handling the same edge cases repeatedly. Over time, we became the experts—at least for our environment.
The vendor had broader knowledge. We had deeper knowledge of our context. Both matter, but there’s something irreplaceable about institutional knowledge built through daily use.
The Takeaway
If you’re building internal tools or small-scale projects, don’t assume you can’t match the security posture of enterprise software. In many cases, you can exceed it—not because you have more resources, but because you have more focus.
The tools are available. The tests are free. And sometimes, the person who cares the most is the one who works alongside you.