Web agencies sell expertise in performance, UX, and SEO, but how many actually implement basic security headers? I decided to find out. I randomly picked 50 agency websites from LinkedIn and audited each one using SecurityHeaders.com. The results?
The Security Report Card
Here's how the grades broke down:
| Grade | % of Agencies |
|---|---|
| A | 8% |
| B | 4% |
| C | 6% |
| D | 30% |
| F | 52% |
Over half scored an F, and nearly 80% earned a D or worse. These grades reflect missing security headers that have been best practices for years. The pattern is interesting: agencies excel at optimizing what users can see but often overlook security headers that browsers check.
What's Actually Missing
These aren't experimental features. They're established security headers that have been recommended for years.
| Header | Agencies Missing |
|---|---|
| X-Frame-Options | 86% |
| Strict-Transport-Security | 82% |
| X-Content-Type-Options | 80% |
| Referrer-Policy | 74% |
| Content-Security-Policy | 70% |
What these headers do:
- X-Frame-Options prevents your site from being embedded in iframes on other domains
- Strict-Transport-Security forces browsers to use HTTPS connections
- X-Content-Type-Options stops browsers from incorrectly interpreting file types
- Referrer-Policy controls what information is shared when users click links
- Content-Security-Policy helps prevent cross-site scripting and other code injection attacks
While missing these headers doesn't guarantee a security breach, implementing them significantly improves your security posture.
Why These Get Missed
It's rarely deliberate. In most teams, it's simply a process blind spot:
- Headers are invisible to clients
- They don't affect visuals or performance metrics
- Teams move fast and reuse old deployment templates
- Manual checks are tedious and easy to skip
- Once configured, they're rarely revisited
Security headers often get documented but not continuously monitored.
The Quick Win
Want to improve your security grade significantly? Add these to your Nginx config:
add_header X-Frame-Options "SAMEORIGIN" always;
add_header Strict-Transport-Security "max-age=31536000" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
That's it. Four lines that add meaningful security layers. For additional protection, consider implementing a Content-Security-Policy using nonces or hashes (see OWASP's CSP Cheat Sheet). Using Apache or .htaccess? Check MDN's HTTP Headers reference.
The Wake-Up Call
If you build or maintain sites, check your own domain first, then your clients'. SecurityHeaders.com gives you instant results. Big thanks to Scott Helme and team for this excellent free tool!
Manually checking 50 sites took me hours, which is exactly why I built Achilleus to facilitate security header monitoring across multiple sites.
And you, what's Your Security Grade?
Check your site and share your grade in the comments below 👇
Top comments (2)
his is such an eye-opening post — honestly, it’s surprising how many agencies still skip the basics. I’ve seen the same issue while auditing client sites; headers like HSTS and CSP are often completely missing. Appreciate that you shared actual data and quick fixes — those 4 lines for Nginx should be mandatory in every deployment template. Great reminder that “secure by default” isn’t just a slogan.
I'd love to run the same experiment with SSL, though that will likely take longer.