In this article we briefly explore website security. Do note a major part of website security is a ‘Content Security Policy’. You can find this in a separate article here. Content Security Policy.
Cross-Origin Resource Sharing
Cross-Origin resource sharing (CORS) is when browsers request infomation from multiple sources. For example a website you are viewing may have a Google map embedded into their site to show their location. The Google maps is part of Google and so that information needs to get fetched as well as the rest of the website from the original search.
Generally speaking this is taken care of natively by the browser as a default.
HTTP Strict Transport Security
This is quickly becoming pretty moot these days. Almost all websites are moving over to HTTPS rather than the traditional HTTP websites we have used for years. With all my website builds and client work I only use HTTPS.
HTTP stands for Hypertext Transfer Protocol and it is what your computer uses to request website details on any given website you are looking for. For example, searching for something on Wikipedia - your computer will send a message to the web, asking for a page from Wikipedia. That page will be found and sent back to your computer.
The ‘S’ part stands for secure. Meaning a website with HTTPS has a security certificate guaranteeing the communication between your computer and the website you are looking for is done securely.
X-content-type-options gives us the option to block MIME sniffing attacks. MIME sniffing, in essence, is the ability for the browser to quickly assess what type of file it is dealing with and how to process it. This is called ‘sniffing’. The MIME attack manipulates this process and can fool the browser into thinking they are dealing with a different file type. This can make it easier for the attacker to then perform an XSS attack (see below for more details).
To block these attacks we add this piece of code to our security file.
_headers file X-Content-Type-Options: nosniff
.htaccess file <IfModule mod_headers.c> Header set X-Content-Type-Options nosniff </IfModule>
X-frame-Options (XFO) protects your website from clickjacking and likejacking. Clickjacking/likejacking are similar in approach. In essence, this is when attackers create an iframe and put your website inside that iframe. The iframe keeps your website self-contained inside whilst being invisible. On many occasions, you will have no idea your website is even inside an iframe.
With the website inside they are then able to add further elements to the page (again invisible) with the aim to overlap links or buttons on your site. When a user clicks on one of your buttons, a like button on Facebook for example - they can take that like and point it to another page completely.
In summary, the idea is the attacker puts a fake button on top of your real button. When that button is clicked it is the attackers’ button that is activated instead of the original. The attacker can then link their button to whatever like button they desire. So when a user clicks the like button they are inadvertently liking a completely different page. This obviously has different levels of complexity and diversity.
_headers file X-Frame-Options: DENY
.htaccess file - choose one of the three options <IfModule mod_headers.c> Header set X-Frame-Options "deny" Header always set X-Frame-Options "sameorigin" // allows only within your own site. Header set X-Frame-Options "allow-from https://example.com/" // allows only from specific servers. </IfModule>
X-Frame-Options is now included within the content security policy. Adding this code for modern browsers is not necessary - only older browsers require it.
XSS attacks, known as cross-site scripting attacks are where attackers can insert code/scripts into your own website. As a rule browsers have a built in security policy which loosely means websites can only share data with another website if the host and port number are the same. This is called the same-origin policy.
In other words attackers can trick the browsers into loading malicious code making the browser think it is all part of the original source code of the website. There are whole host of ways an attacker can succeed in this endeavor XSS cheat sheet.
This article on the 5 practical scenarios of XSS attacks can help shed light on what these attacks actually look like.
_headers file X-XSS-Protection: 1; mode=block
.htaccess file <IfModule mod_headers.c> Header set X-XSS-Protection "1; mode=block" </IfModule>
S-XSS-Protection is now included within the content security policy. Adding this code for modern browsers is not necessary - only older browsers require it.
Final thoughts of website Security
This is what the final headers file or HTTP header file will look like.
_headers file X-Frame-Options: DENY X-XSS-Protection: 1; mode=block X-Content-Type-Options: nosniff
.htaccess file <IfModule mod_headers.c> Header set X-Frame-Options "deny" Header set X-XSS-Protection "1; mode=block" Header set X-Content-Type-Options nosniff </IfModule>
For the main part of website security you must include a Content Security Policy. This is a more indepth article and you can find it here. Content Security Policy.