My previous articles about frontend security focused on script integrity and the Content Security Policy.

Now, It's time to look at what can be done server-side.

For these server-fixes, I'm going to use Cloudflare.

Cloudflare has a bunch of services — in their own words:

Cloudflare secures and ensures the reliability of your external-facing resources such as websites, APIs, and applications. It protects your internal resources such as behind-the-firewall applications, teams, and devices. And it is your platform for developing globally scalable applications.

They have a super-intuitive user-interface - and for most purposes, it's free!

You can find guides on their site on how to move your DNS records etc.

But maybe there's no need for you to use Cloudflare?

Before I continue, check your security-headers here: https://securityheaders.com/

If you have a red F, let's see how we can improve that with Cloudflare.

Now, the first thing to do on any server, is adding SSL (HTTPS).

In Cloudflare, go to SSL/TLS, select “Edge Certificates” and check the “Always use HTTPS” box.

Just below that, you'll see the “HTTP Strict Transport Security (HSTS)”-entry.

Click on “Change ”, accept the warnings, check “Enable HSTS”, set “Max Age Header” to (minimum) “1 month”, and check “No-Sniff Header”:

UPDATE: To qualify for HSTS preloading, as mentioned in the comments, set Max-Age Header to "12 Months", and enable both "Apply HSTS policy to subdomains" and "Preload".

Now, go back to https://securityheaders.com/

If you had an F before, you should now have a D.

Cloudflare doesn't support the other headers out-of-the-box, but luckily they have something called Workers, where you can add them yourself.

Scott Helme has written an excellent article: The brand new Security Headers Cloudflare Worker

Because the article was written some time ago, you need to manually add the “Permissons-Policy” to Scott's list of “securityHeaders”:

let securityHeaders = {
  "Content-Security-Policy" : "upgrade-insecure-requests",
  "Strict-Transport-Security" : "max-age=1000",
  "X-Xss-Protection" : "1; mode=block",
  "X-Frame-Options" : "DENY",
  "X-Content-Type-Options" : "nosniff",
  "Referrer-Policy" : "strict-origin-when-cross-origin",
  "Permissions-Policy": "geolocation=(self \"https://your.domain\"), microphone=()"
}

When set and done, deploy the worker, and head back to SecurityHeaders:

Wow! - from F to A+ in a matter of minutes.

Ongoing maintenance

Now, even if you've done all the things I suggest in these posts, you shouldn't rest on your laurels. Security is an ongoing activity — you need to test your site whenever a new script is added, update integrity-attributes, test SecurityHeaders etc. Whenever a new vulnerability is discovered, test again.

You can also use services like Probely or Detectify

These services will deep-scan your site and provide a “todo-list” of things, you potentially need to look into. Here's a screenshot from Detectify:

Starting from EUR 39 (Probely) and USD 50 (Detectify), these services will continuously monitor your site for security vulnerabilities.

Conclusion

The world of front-end is constantly expanding. It used to be simple enough to define our vocation: HTML, CSS and JavaScript — but does that include animation, email development, accessibility, SEO, tracking, performance engineering or ... security?

I'd argue that it doesn't hurt to know a bit about XSS attacks, Content Security Policy-configuration, or that SVG files can contain (harmful) scripts — but we would probably need a specific role for that, as it's a big and complex topic.

Every website should have a “Security Health-check” at least a couple of times per year. Whether or not it will be a frontend-job ... time will tell!