Which security measures make sense for a static web site?
I have a static web site. Users cannot log in or perform any other actions. Which of the common HTTP security measures make sense for my site?
Do I need any of these?
HTTPS make almost always sense. Consider that some people may want to avoid letting other people know exactly which pages they visited on your website (e.g. if some pages contain certain type of political content and they browse from a country with a dictator... or more down to earth: if you host something like a porn website, maybe some users don't want to let other people know which kind of videos they like to watch...)
Do you only want the items in your bullets addressed or are you asking for any and all recommendations?
Note that for a static website, there's not much reason (AFAIK) not to offer both HTTP and HTTPS access.
Any advice on securing static websites is welcome. Also, I am looking for more specific answers than "enable all the things, just to be sure".
@immibis If you have HTTPS, there's no good reason *to* have HTTP. Always-more-secure-by-default is increasingly the best practice.
@chrylis The benefit (when applied as a general principle and not necessarily to this site in particular) is accessibility for e.g. embedded systems. (Which these days have enough processing power for HTTPS, but might not have a way to update certificates)
@chrylis Unless this website is accessed by 16-bit toasters which don't implement HTTPS. I hate it when other people decide what I need instead of giving me the choice.
Also ***predict the future***: I'm sure in 6 months you'll need to add that dynamic feature, so plan for that from now.
The common web application attack vectors don't apply to a strictly static website. Without interactive elements there are no accounts to hijack or cookies to steal. Nonetheless, you should provide your visitors with encrypted access - even if you're not hosting delicate content.
Use HTTPS with HSTS to ensure some degree privacy and the integrity of your content to visitors. Adding HPKP to a static site might be unnecessarily paranoid and you have to be careful when deploying it. The other discussed security measures are mostly irrelevant for a static site, but they are so simple to implement that you might still decide to use them.
Yes, do it. With free SSL certificate providers like Let's Encrypt you need a very good reason not to switch. HTTPS protects privacy and integrity of the transmitted data which is desirable even with static content.
Scenario for an integrity violation: If you offer downloads, a man-in-the-middle attacker could tamper with the files to deliver malware. Example of a privacy violation: My employer, the owner the WiFi hotspot I'm connected to or my ISP could all see which exact articles I'm reading and content I'm downloading from your site. With HTTPS however, I would mostly expose metadata (the IP address I'm connected to, the hostname due to SNI, etc.).
HTTP Strict Transport Security
Yes, do it. HSTS helps to enforce that users only use HTTPS to connect to your website, thereby preventing SSL stripping attacks. If you roll out HTTPS, it makes a lot of sense to follow up with HSTS. It's easily implemented by adding an additional response header, like this:
Since HSTS only takes effect from the first time a user encounters the header (TOFU model) and until the
max-agetimeout is reached, you might even want to submit your site to the HSTS preload list. This has the effect that users will start connecting via HTTPS from their very first visit.
Be aware that it's troublesome to switch back to plain HTTP after enabling HSTS.
HTTP Public Key Pinning ("Certificate Pinning")
It depends. While HSTS tells the browser to strictly use HTTPS for a given time, a HPKP header specifies which certificates the browser should trust in the future. Pinning public keys from the certificate chain protects users against an attacker replacing your certificate with a rogue one. Such an attack is very unlikely since the adversary would need to compromise a CA to be able to issue rogue certificates (although that has happened before). Additionally, you have to be careful when setting up HPKP since a defective deployment could make your site unavailable to previous users.
Detectify Labs have an excellent article on HPKP with a more optimistic conclusion:
So should you use HPKP? Yes, you should. If you pin correctly, the chance of everything going south is pretty small.
Content Security Policy
Yes, but you might not really need it. The CSP was created to mitigate XSS and related attacks by limiting which resource type from which origin is allowed to be loaded by your site. Since you have a purely static website and probably don't embed external sources at all, it might not be an actual attack vector. A sensible policy would depend on which kind of resources you are loading. For example, this restrictive policy header only allows content from the same origin:
Content-Security-Policy: default-src 'self'
Yes, why not. Clickjacking attacks trick a user into unwittingly interacting with your website through a disguised frame. If you have no interactive elements however, there is no actual damage to be done. (In a better world cross-origin frames would be an opt-in feature, though.) The implementation is straightforward. This example disallows any frame embedding at all:
Note that the XFO header has been declared obsolete in favor of the
Content-Security-Policy: frame-ancestors 'none'
Content sniffing protection
Yes, why not. If you don't correctly declare content types, browsers might guess (sniff) the type (although that behavior has become less common). This is particularly dangerous with user content that is supposed to be non-executable but determined to be an executable format after sniffing due to a missing content type. With your static site that will hardly become an issue. Just to be safe you could add the following header to prevent sniffing (but it's not a replacement for properly declared MIME types):
Also have a look at the OWASP Secure Headers Project for more details on security-relevant headers with some real-life examples.
Where does `HSTS` and `HPKP` store the connection parameters for future connections? (client side?) If you were "locked-out" due to pinning errors, couldn't the user just connect with a different (or new install) browser?
@KevinFegan Yup, client side. Sometimes it's shipped built-in to the browser. Users do not usually like to reinstall their browsers, so they're likely to go elsewhere.
HTTPS connections do leak the domain name (not just the IP address) because of SNI. There is no need to sniff the DNS traffic.
@AyeshK True, since all modern browsers support SNI you don't need to bother with DNS. I'm adding that to the answer.
The article on pinning fails to mention that you should have a backup certificate in the vault which is also pinned, in case your real certificate (or the CA you use) is compromised. If you pin just your current certificate you can never change it. This increases the cost and risk of pinning to a point that I think it is not worth it for a static site.
"the adversary would need to compromise a CA" or get the user to install another CA.
It is common for corporate pc's to have a corporate CA and all https traffic to be man in the middled with the user being served the corporate signed cert rather then the CA signed one, HPKP also protects against this sort of attack.
- Strict transport security
- Certificate pinning
These protect the transport of the data against sniffing and against manipulation. This protection is not only for the request from the browser but also for the response and thus makes perfectly sense even for a static site.
- Content security policy
If you don't include content from any other side it is probably not necessary but does not harm either. If you include external content outside of your control like ads, images, fonts, scripts it makes sense to restrict it.
- Clickjacking protection
If you include links to other sides which then act based on a trusted referrer (i.e. your site) or if you include social media buttons or similar, it makes sense to restrict framing. If not it does not harm unless you explicitly want your sites to be frameable by others.
- Content sniffing protection
If you serve content which might be interpreted differently when content sniffing is active (for example serving HTML as text/plain to show source code) it makes sense to enable content sniffing protection. If not it does not harm.
What about web application filtering and using a CDN? IMHO those aren't overkill for any web site.
@ToddWilcox: I don't think that this comment is relevant for the question which asks about which measures make sense for static sites compared to dynamic sites.
@ToddWilcox: You can DDos, you can hack the server, you can hijack the domain... - all of is true but none of this is related to this question. Its not asking about optimal protection, its asking how much sense some specific protections make.
@SteffenUllrich Yes, but, "how much sense it makes" depends on how much traffic the site expects, and how harmful it would be if the site went down --- neither of which were mentioned by the OP.
Static sites do get hacked and defaced all the time. Static sites are also victims of DDoS attacks and are even brought down by unexpected traffic loads. So as jpaugh mentions, if a static site is an important part of the public face of an organization, it's definitely worth investing some money in web application security and light CDN services, for any size organization.
There are so many things to consider while you are planning for website and especially when it is your business website you always need to pay extra attention on it. However static website tends to have less number of risks than other sites but still it should have followed important security aspect as you have mentioned above. The details given here is only to share additional knowledge about security concerns for different types of sites. I don’t need to add much here because @Arminius and @Steffen have cleared most of doubts. Still let me add my views:
Numbers of websites have had belief that their static sites not require SSL Certificate but now they are considering SSL as an important aspect of their site. First reason is Google’s announcement on ranking boost; another reason is treatment to non-HTTPS sites by browsers.
HTTP Strict transport Security or HSTS is security protocol to protect websites from cookies hijacking and downgrade attack simultaneously indicates web server to allow only secure HTTPS connection on web browser and other agents. This policy add extra layer on HTTPS security and help websites and its users to stay secure.
Attacks like XSS (cross site scripting), code injection not only damage performance of website but also kill reputation by putting intolerable content. Whether it is static or dynamic site, injection of malicious code can put website at trouble. Use of Anti-Malware software and regular Vulnerability Assessment can help websites to prevent such unwanted attacks.
HTTP Public Key Pinning (HPKP) is an effective method to avoid attackers by restricting them to issue fraudulent certificate with malicious intension. HPKP often fallaciously popular as Certificate Pinning, while it is a security mechanism to allow HTTPS websites to protest against attacker to stop issuing fraudulent certificates.
This technique is very popular on pirated movie sites where they forwarding users to false page or download. Sometimes Clickjacking technique can summatively used with Malwartising activity where attackers spread Malware by impersonating advertising something.
Content sniffing is type of capturing or monitoring the content that resides in byte and thereby attacker can assume about the content’s file type. Content sniffing refers to inaccurate metadata that is set to render the file to be deduced in a right manner.
I don't think cookie hijacking, XSS, or clickjacking are applicable to static websites.
this is just my opinion:
- Strict transport security
- Content sniffing protection
- Certificate Pinning
Why would you need to protect, on a static site, from sniffing if you're not presenting custom nor protected information? I guess the information on a static site is public, so no need to cover this.
- Content security policy
If you're not including any dynamic content, nor external content (static site does not). Then this one is neither required. As there's no possible XSS attack.
- Clickjacking protection
As Steffen Ulrich this one is not required unless you explictly set your site as frameable by others.
So, In conclussion: if you're setting a strictly static web site, you do not need any of those security measures.
In any case if you think you may edit this site in a near future to make it more dynamic, then add every security measure possible.
You may want to support HTTPS on a static site to protect the *integrity* of the site. For example, to prevent "free" WiFi hotspots from inserting advertisements into your web site.
Well @Sjoerd you are right, but this case is not so common. Not many people use "free" WiFi hotspots. And not everyone of those inserts advertisements. In any case you are right, but strictly, he does not require any security measure of those.
"Not many people use "free" WiFi hotspots." I'd like to argur against that; *many* people do that (at least in my country). Think McDonalds hotspots. But you're probably right about the advertisements; can't comment about that.
Well, you're right, i wanted to say that proportionally, there is not much people that browses through free wifi hotspots, so it's suppossed that only once or twice in year, somebody will browse his static webpage from a public wifi point.
HTTPS should be used to ensure the integrity of HTTP connections. Unfortunately, it's not only WiFi hotspots that modify data sent using plaintext protocols: https://duckduckgo.com/?q=isp+inject+ads :(