Security headers are instructions your server sends to every visitor’s browser, telling it how to behave defensively — refuse to load a script from an unapproved source, always use an encrypted connection, don’t let another site frame yours in a hidden window. Most sites send none of them by default, leaving the browser to make its own, less protective assumptions.
Security headers implementation - CSP, HSTS
Security headers like CSP and HSTS implemented, built around what your site actually loads.
- Full backup taken before we start
- If we can’t fix it, you get your money back
- We never ask for your own password
What we need from you
- FTP, hosting panel, or CDN access, depending on where headers need to be set
- Confirmation of every external resource your site legitimately loads (fonts, scripts, embeds), so a strict policy doesn’t break them
- Your risk tolerance for a strict Content Security Policy versus a more permissive one
This or something else?
| You want security headers like CSP and HSTS implemented for your site | This fix covers it |
| You want the underlying SSL/TLS certificate configuration improved, a related but distinct fix | SSL/TLS configuration grade improvement |
| You want a full firewall, not just response headers | Firewall (WAF) plugin configuration, a broader layer |
| A specific header is already set but breaking something on the site | Worth describing to us directly — likely a Content Security Policy needing a specific exception added |
What we do
- Audit which security headers are currently missing
- Inventory every legitimate external resource your site loads
- Build a Content Security Policy that permits legitimate resources and blocks unapproved ones
- Implement HSTS and other applicable headers appropriate to your setup
- Test the site thoroughly for anything broken by the new policy
- Adjust and retest until the site functions normally under the new headers
What is included
- Applicable security headers implemented and tested
- A Content Security Policy built around your actual legitimate resources
- Full functional testing after implementation
- A written note on what was set and why
Not included
- SSL/TLS certificate configuration itself, a separate, related fix
- Ongoing adjustment as you add new external resources or scripts later
- A web application firewall, a separate layer of protection
- Fixing an unrelated site issue discovered during testing
Questions about this fix
Could a strict Content Security Policy break parts of my site?
Yes, if it's built without accounting for everything your site actually loads, which is exactly why we inventory your real external resources first rather than applying a generic policy.
What's the practical benefit if my site already looks and works fine?
These headers don't change how your site looks — they instruct browsers to refuse specific categories of attack (like loading a malicious script from elsewhere), which isn't visible until it's the thing that stopped an attack from working.
Do I need to redo this every time I add a new plugin or embed?
If a new addition loads resources from a domain not already permitted in the policy, yes, that specific header would need updating — worth flagging when you add something significant.
Is HSTS the same as having an SSL certificate?
No — HSTS instructs browsers to always use the encrypted connection even if someone types the non-secure address, which requires an SSL certificate already being in place to work correctly.
Will visitors notice any difference after this is implemented?
No visible difference for legitimate visitors — the headers only change behaviour in scenarios that would otherwise be exploited, which shouldn't affect normal browsing at all.
Related fixes
If this is the second time this year
A bad update breaking the site is a symptom of updates not being tested first. Care plans run every update on a staging clone before it reaches your live site, which is the actual fix for this happening again.
Your access, your rules
Create a separate admin account for us and delete it when we are done. For anything else, we get in touch and agree a method — never a form field on this site, never by reply to an email.
We back up first, always
Before anything is touched we take a full backup and keep it for 30 days. If a fix goes wrong, we put the site back exactly as it was.
If it is not what you bought
If the problem turns out smaller than what you ordered, we refund the difference. If it is bigger, we stop and send a quote before doing any extra work.
If we cannot fix it
You get back what we received. Diagnosis is on us — you only pay when the problem is actually solved. The payment processor takes its fee before the money reaches us, so we never hold it and it is not ours to return. That is true here as everywhere else.
If it comes back
Reply within seven days of delivery and we put it back on the bench at no cost. The fix is not finished until it holds.
What we are responsible for
If something goes wrong with a fix, our responsibility is limited to what you paid for it. We take a full backup first so mistakes can be undone, and we tell you before doing anything outside what you bought.