There is a school of thought which says that static sites are inherently more secure than dynamically-served ones. This may be true, to a certain extent at least, but you still need to know how to secure your static site. Here is a quick guide to help.
4 Tips to secure your static site
When you’re looking at how to secure your static site, there are two key steps you need to know. These are as follows. Use HTTPS. Up your game with HTTP Strict Transport Security (HSTS). Additionally, you may need to implement the Content-Security-Policy. Clickjacking protection and content-sniffing protection may also be good ideas.
1. Use HTTPS
Ask any cybersecurity expert how to secure your static site and the chances are their first response will be to use HTTPS. With dynamically-served websites, this is highly recommended. With static websites, it’s basically non-negotiable. There are three main reasons for this.
Firstly, it will ensure your users have some degree of privacy. If you use standard HTTP, then the site will essentially broadcast what users are doing. You may not think this is a major issue, especially if you are serving “work-friendly” content. Up until relatively recently, you might have been right, or at least, not entirely wrong. These days, however, people often use mobile data and public WiFi hotspots, which increases the need for effective security at the server-side.
Secondly, it vastly cuts down on the opportunities for man in the middle (MitM) attacks, which, for completeness are often associated with users connecting through insecure networks - such as public WiFi connections.
Thirdly, using HTTPS can improve your search engine rankings. At the moment, HTTPS versus HTTP is more of a tie-breaker than a major ranking factor. That, however, can be important enough, especially if you have a new website, which is only just becoming established or if you’re targeting competitive keywords.
2. The practicalities of implementing HTTPS
Hosting providers increasingly offer free upgrades to HTTPS. People running dynamically-served websites would need to look at the implementation carefully to ensure that it was robust enough for their needs, especially if they were handling sensitive data.
People running static websites, by contrast, are only likely to need a basic implementation, because of the strict limits on what can be done with static websites. In short, if nothing else, you have no reason not to upgrade.
If you’re running a static website on a static file server (e.g. AWS) rather than a proper web server, then implementing HTTPs is likely to be rather more of a technical challenge and, even if you have an in-house IT team, you may need to get extra help. You might also find that it’s more expensive than you expected.
Even if you’re on a tight budget, do not be tempted to let this put you off implementing it. Remember, that all the cost savings you make through hosting your static site on a file server could be negated if hackers take it down and you lose business.
3. Up your game with HTTP Strict Transport Security (HSTS)
Having established that you need to use HTTPS, it makes sense to go the extra step and enforce HSTS. This basically forces visitors to use HTTPS rather than allowing them to “opt-out” and go back to plain old HTTP. The reality is that most legitimate visitors won’t want to do that but hackers might want to try SSL stripping attacks. These are a sub-form of MitM attacks and are a major security hazard even for static websites.
For the highest level of security, it’s recommended to submit your site to the HSTS preload list. This ensures that the site is loaded as HTTPS from the very first click rather than waiting until the user sees the header.
4. You may need to implement the Content-Security-Policy
In principle, a fully static site doesn’t need the CSP header because it doesn’t interact with external sources and hence isn’t vulnerable to Cross-Site Scripting (XSS) attacks. In the real world, however, these days, a lot of websites are more realistically described as “mostly static” rather than “completely static”. For example, they may use applications with JavaScript frameworks, templating engines, or back-end databases. If any of these apply (or if you just think they might), then it’s probably a good move to implement the CSP header.
Clickjacking protection and content-sniffing protection may also be good ideas.
This is another area where theory doesn’t necessarily meet practice. In principle, you shouldn’t need either of these since you will have no interactive elements. This may, however, not be entirely true in practice.
Please click here now to have your website scanned, for free, by cWatch from Comodo.
