Data/Cyber/Cloud Security, Privacy, Website Security, Data Encryption, Malware/Viruses, Open Source Intelligence, Cyber Defence, Data Breaches
Last month I moved my website to a new server and rebuilt it from scratch along with: double username/passwords, double ninja firewalling, restricted TLS configuration, security headers, two factor authentication and a SaaS WAF (website application firewall), and more of course.

Many of us technical folk have seen and used SSL Labs by Qualys which gives me a “A” rating though it states I still have TLS 1.0 available which is incorrect. SSL Security Test by ImmuniWeb gives me a “A+” (if only I got this during school GCSE’s!) and states only TLS 1.2 + 1.3. Odd Qualys gets it wrong.

The technical security controls listed in paragraph one are known apart from security headers which are less known about and used. Headers are sent/set by: WAF, load balancer, web application, web server and other devices, and they are sent from the website to the end users’ browser.

They tell the end users browser to do something, typically enforce a micro policy and the aim is to protect the browsing users rather than the website. For instance, only serve content over HTTPS or block XSS (cross site scripting) and a lot more. Below are the ones I use with a high-level explanation and there are many more:

Strict-Transport-Security (HSTS)
It tells a browser only to transfer content encrypted and force HTTP to HTTPS. It has a cache time set (seconds) and can cover sub-domain names to.

Referrer-Policy
First of all, what does the word mean? If you are on Yahoo and click on a search result item, you hit the end target and they can see where you came from. Who cares? Imagine you were CIA.gov and had a link on an intranet site internally. You would not want people knowing you had a link of theirs. On this policy you can stop the referrer tag from being sent and a lot of more precise options.

Feature-Policy
This allows or disallows the use of items such as: webcam, microphone, gyrometer, magnetometer etc. and you can specify the source. This can allow the microphone only to work on sources from the actual domain and block 3rd party scripts from abusing the end browser PC functions.

X-Frame-Options
An anti-clickjacking technique to block the use of frames or iframes and specify sources which is allowed. For example, allow iframes from the official domain but block www.iammalware.com/script.js for instance.

X-Content-Type-Options
The title does not explain itself well and it relates to “MIME sniffing”. Take a .JPG file which should be an image file and harmless or it should be. “MIME sniffing” lets the browser guess what the file is and if “nosniff” is enabled the browser would run the .JPG as a straight up image file not a script if tampered with.

Content-Security-Policy
This is one of the most popular and is anti-XSS. It lets you specify the sources of: css, images, objects, scripts, fonts and more. Thus, only allow .JS to run from the same domain which would block scripts hosted externally from executing in the user’s browser.

Expect-CT
This is the HTTP Public Key Pinning (HPKP) replacement and I liked HPKP which let you tell browsers to only accept a certificate by fingerprint. HPKP was rarely used, at times not setup correctly and now some browsers do not support it. CT stands for Certificate Transparency and was created by Google but it is public and not for Chrome only. It is a massive open databases of issued certs and you can search it at https://ssltools.digicert.com/checker/views/ctsearch.jsp. You might be able to spot dodgy certs issued. This header checks the massive database of known CA’s and will flag it to the user browser if the cert is not on the known list.

Finally, why does my website show no headers are set?
The WAF cannot challenge the lookup site since it is not a normal browser with a standard user agent string. Proof below with the WAF temporally in monitor mode.