Long time no hear! My last blog post has been a while ago, I’m sorry for that. I may have mentioned possible reasons for that (or maybe excuses) in some other posts already. I’m busy in the office, and when you’re working as a customer, there is not the same level of troubleshooting (and thus the source for blog posts) as when you would work as a partner (vendor => partner => customer, from an IT tech perspective). I know, that might be only an excuse. We’ve got plenty of servers, stuff in the cloud, and therefore one may say there are plenty of problems. But no, there’s not much. Honestly. But anyway, I’m still keeping the troubleshooting stuff on my radar, and if there will be some good and beefy issues, I’ll document that and blog about it. Because in IT, you’ll be probably not alone with that problem. And any blog post can help.

What’s up then?

Today’s topic is not about virtualization, networking, storage, or anything else in that sphere. It’s about an update on my website’s performance and security.

Recently we had a discussion in our team on how to improve website performance in general, how complex it could be, what solutions could be applied, and who should be on board with such a project. After the “official” part we had a chat in our core team about our personal websites, website monitoring, performance, etc. and we stumbled across some speed test websites. I mean, we’re all somehow nerds, isn’t it? No offense!

I tested my website for performance (and I’m testing it on a regular basis with GTmetrix) to see if there is potential for optimization, or if I just screwed up somewhere. I also use several different tools to test the website performance, especially when I changed something big (like the theme, or did some upgrades). My main tools are GTmetrix, Pingdom Web Speed Test, and Google PageSpeed Insights. The general performance of my website is pretty good. The website itself is hosted in Switzerland, and the GTmetrix test is performed in Vancouver, Canada. The result is nice:

New kids on the block!

But there is now a new kid in town: WebPageTest.org

Ok, to be honest, I don’t know how long this website exists already, but it was definitely not in my toolbox until yet. This test is not looking only for performance and ways to improve the performance, but it is also looking for possible security issues on your website. It looks for general issues, like if Strict Transport Security is enabled (HSTS), if there is a content security policy active, or possible XSS issues. And I had some issues, on the website as well as personal when I did the first run:

A big, fat, and red F for the security score! What’s going on here?

The detailed report showed me the following security issues:

High Severity: Strict Transport Security
High Severity: Content Security Policy
Medium Severity: X Frame Options
Low Severity: X Content Type Options
Low Severity: X XSS Protection

For details about these checks, you can visit the report history of my website here.

First steps to solve the problems

First, I tried to tackle the Strict Transport Security HSTS. I checked that on my current hosting platform, and thanks to Nginx (which is my webserver), I could just enable that feature, literally one click and a number to set the age for HSTS (in seconds). A few minutes later, I’ve had a red E in the security score. Not much of an improvement, but at least something!

Well done, but what’s next? There are still some issues to look into:

High Severity: Content Security Policy
Medium Severity: X Frame Options
Low Severity: X Content Type Options
Low Severity: X XSS Protection

Solving the rest of the problems

With some research, I’ve found out that this can be all done in the .htaccess file on the webserver. And it only needed like four lines of code for that. Awesome!

Header set Strict-Transport-Security “max-age=15768000"
Header set X-Frame-Options "sameorigin"
Header set X-Content-Type-Options nosniff
Header set X-XSS-Protection "1; mode=block"
Header set Content-Security-Policy "default-src 'self' 'unsafe-inline' 'unsafe-eval' https: data: *.yourdomain.com;”

After saving the .htaccess file, I directly run the test again, and bang! A big, gree, nice A+ on the security score!

What’s next? Speeeeeed!

Well, when you check the score report, you’ll see the X at the end for the “Effective use of CDN”. I wasn’t using a CDN (Content Delivery Network) until yet. As I already know AWS stuff, and did there already many things in the past to see how it is working and so on, my first idea was to leverage the AWS CloudFront CDN for my blog. So I searched for a plugin that supports setting up AWS CloudFront on WordPress, and I found “Amazon AWS CDN“. With this plugin (having an Amazon AWS account is required), you can easily create a new CloudFront distribution. But some features are just not working as expected with that plugin. I wanted to use a custom domain, something like cdn.driftar.ch, but that somehow doesn’t work. Well, the feature is there, but I can’t enable it. Maybe I can troubleshoot that somewhen.

But at the end, the black X in the score report is now a green tick:

And if I compare the speed reports from GTmetrix, it’s looking at least a bit better then before implementing the CDN:

Conclusion

So far, so good! I have implemented HSTS on the Nginx web server, implemented some content security policies through the .htaccess file, and optimized the performance a bit by implementing CloudFront as my CDN. I’d like to close this blog post with the words of wisdom of the well-known farmer 😉

Update on website performance and security