Blog

I normally like my last blog post of the year to end with a year in review. In light of being in Tier 4 local restrictions, there isn't much to do during the festive period unlike previous years. So I have decided to use this time to tinker around with various tech-stacks and work my own site to keep me busy.

Whilst making some efficiency improvements under-the-hood to optimise my sites build and loading times, I randomly decided to check the security headers on securityheaders.com and to my surprise received a grade 'D'. When my site previously ran on the .NET Framework, I managed to secure things down to get graded an 'A'. I guess one of my misconceptions on moving to a statically-generated site is there isn't a need. How wrong I was.

A dev.to post by Matt Nield explains why static sites need basic security headers in place:

As you add external services for customer reviews, contact forms, and eCommerce integration etc., we increase the number of possible vulnerabilities of the application. It may be true that your core data is on accessed when you rebuild your application, but all of those other features added can leave you, your customers, and your organisation exposed. Being frank, even if you don't add external services there is a risk. This risk is easily reduced using some basic security headers.

Setting security headers on a Netlify hosted site couldn't be simpler. If like me, your site is built using GatsbyJS, you simply need to add a _headers file in the /static directory containing the following header rules:

/*
X-Frame-Options: DENY
X-XSS-Protection: 1; mode=block
Referrer-Policy: no-referrer
X-Content-Type-Options: nosniff
Content-Security-Policy: base-uri 'self'; default-src 'self' https: ; script-src 'self' 'unsafe-inline' https: ; style-src 'self' 'unsafe-inline' https: blob: ; object-src 'none'; form-action 'self' https://*.twitter.com; font-src 'self' data: https: ; connect-src 'self' https: ; img-src 'self' data: https: ;
Feature-Policy: geolocation 'self'; midi 'self'; sync-xhr 'self'; microphone 'self'; camera 'self'; magnetometer 'self'; gyroscope 'self'; fullscreen 'self'; payment 'self'

When adding a "Content-Security-Policy" header be sure to thoroughly re-check your site as you may need to whitelist resources that are loaded from a different origin. For example, I had to make some tweaks specifically to the "Content-Security-Policy" to allow embedded Tweets to render correctly.

My site is now back to its 'A' grade glory!

Useful Links

• Check Your Website Headers People
• How to ensure you have the right security headers
• Netlify Custom Headers
• Netlify Playground - Headers Tester

A website can tell the public a lot about you, from the things you want people to see and other things you probably would not. HTTP Headers can divulge things about your website that you wouldn't necessarily want to make public and its up to the individual to make a decision on what headers they're willing to expose. But what I would recommend is to at least analyse any site prior to moving to a production environment.

Why all of a sudden am I talking about questioning your website HTTP Headers?

It was only by chance when perusing StackOverflow I came across a question about securing HTTP headers, I was directed to a site called securityheaders.io. I immediately entered this very site for scanning, thinking it would fare quite well. But boy oh boy was I wrong!:

Based on this result, does this make my website vulnerable? To a certain extent yes. By default you're exposing some key information to potential hackers about how your website is built. For example, here is a simple list of HTTP Headers that could be returned from the server:

• Web server
• Framework version
• Cache handling
• Cross-site scripting access
• Referrer policies

Now based on that list alone, what HTTP headers would you hide? From having my eyes opened by the report generated by securityheaders.io, as a minimum I would hide anything that shows what technology, framework and server platform I am using. If there happens to be an exploit on the very server or technology you are using, we don't want the whole world to know that especially if you happen to be hosting a high traffic website.

I decided to correct all the issues highlighted by securityheaders.io and spent additional time obfuscating some additional headers. Now I can proudly say I've passed. There is just one blemish against the report to do with the "Content-Security-Policy" header, which defines approved sources of content that the browser may load.

I been tweaking around with the rules for this header and I'll be honest when I say it shafted the administration dashboard of my the content management system I use for my site - Kentico CMS. So before I reinstate the header, I need a little more time tweaking.

Another great site to use to analyse the security of your site (.NET sites only) is ASafaWeb, which scans for common configuration vulnerabilities.

Recommended Links

• Improving security in ASP.NET MVC using custom headers
• ASafaWeb
• Shhh… don’t let your response headers talk too loudly

I decided it was time for my trusted Nexus 5 and I to part ways. We had many good times over the last few years we had known each other. But as things sometimes unfortunately turn out, our time together finally came to an end. The battery life was starting to wane and I really need a phone with a larger capacity - more than 16GB.

Enough with the sentimentality...

I am now the proud owner of a Nexus 6P.

And what a beauty she is!

In getting the Nexus 6P, I am about to sell my dear Nexus 5 on eBay, so that it may grace someone elses life in a positive way just as it had done mine. It's in very good condition and still looks brand-spanking new. The only thing that I need to ensure is that the phone is wiped clean - inside and out. Even though I carried out a factory reset, I read doing this alone is not enough to make your previously stored information fully un-recoverable.

To be completely sure that the device has had a complete wipe down, you need to ensure the Android device is encrypted prior to carrying out the factory reset. You can check if the phone is set to be encrpyted by going into Settings > Security > Encryption. By doing this, the encryption process will scramble your data and if some data is left after the factory reset, a key would be required to unecrypt it. For the general user, this should suffice.

I decided to take things a step further, just to be 100% sure. I found a very good post on StackExchange Security that states the following:

Factory resets reset your phone to a stock like state but does not remove your data, just applications. This leaves some data behind. The best way to prevent this data from being recovered is to encrypt the phone, and use wipe data/factory reset from the recovery menu. This way you don't have to download a ton of data and you can be fairly certain your things are secure.

If you're not that worried, encrypting, and data/factory reset from the recovery menu is probably enough.

Forgot to mention why the recovery mode data/factory reset. It formats the user data areas as well as the application area, and is far more thorough/secure than the one inside of the android OS and will prevent you from download junk data. It just flat out gets rid of it.

To get to the recovery console on the Nexus 5 for resetting:

1. If your phone is on, turn it off.
2. Press and hold the Volume Down and Volume Up buttons, and then press and hold the Power button at the same time until the phone turns on. You'll see the word "Start" with an arrow around it.
3. Press the Volume Down button twice to highlight "Recovery."
4. Press the Power button to start Recovery mode. You'll see an image of an Android robot with a red exclamation mark and the words "No command."
5. While holding the Power button, press and release the Volume Up button once.
6. Press the Volume Down button twice to highlight "wipe data/factory reset" and press the Power button to select it.
7. Press the Volume Down button seven times to highlight "Yes - erase all user data" and press the Power button to select it.
8. After the reset is complete, press the Power button to select the option to reboot your device.

Don't forget to also revoke account access as an extra measure by logging into your Google Account and clicking the "Remove" button (https://security.google.com/settings/security/activity).