151

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?

Sjoerd
  • 28,707
  • 12
  • 74
  • 102
  • 51
    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...) – Bakuriu Nov 13 '16 at 16:51
  • Do you only want the items in your bullets addressed or are you asking for any and all recommendations? – Todd Wilcox Nov 13 '16 at 16:57
  • yes, and you need more. – rook Nov 13 '16 at 17:42
  • Note that for a static website, there's not much reason (AFAIK) not to offer both HTTP and HTTPS access. – user253751 Nov 13 '16 at 21:37
  • 7
    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". – Sjoerd Nov 14 '16 at 09:58
  • @Bakuriu Good point. Please consider changing your comment to an answer. – Sjoerd Nov 14 '16 at 13:47
  • 3
    @immibis If you have HTTPS, there's no good reason *to* have HTTP. Always-more-secure-by-default is increasingly the best practice. – chrylis -cautiouslyoptimistic- Nov 15 '16 at 00:26
  • @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) – user253751 Nov 15 '16 at 00:34
  • 2
    @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. – Dmitry Grigoryev Nov 15 '16 at 15:27
  • 2
    What does 'static' mean exactly? Is it entirely written in HTML and CSS, or is there any Javascript, or even any code that runs on the server? – bdsl Nov 16 '16 at 13:50
  • Also ***predict the future***: I'm sure in 6 months you'll need to add that dynamic feature, so plan for that from now. – sampathsris Nov 17 '16 at 05:55
  • @bsdl, I had [this site](https://www.sjoerdlangkemper.nl/) in mind for this question. It has just HTML and CSS. No client side code (e.g. Javascript, Flash) and no server side code (e.g. PHP). No advertisements or other content from third-party sites. – Sjoerd Nov 17 '16 at 07:55
  • 1
    @Bakuriu - but HTTPS doesn't stop other people knowing which pages (or videos) were visited on the website. – Chris Becke Nov 17 '16 at 11:32

4 Answers4

132

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.

TL;DR

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.

HTTPS

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:

Strict-Transport-Security: max-age=31536000

Since HSTS only takes effect from the first time a user encounters the header (TOFU model) and until the max-age timeout 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'

Clickjacking protection

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:

X-Frame-Options: Deny

Note that the XFO header has been declared obsolete in favor of the frame-ancestors CSP directive:

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):

X-Content-Type-Options: nosniff

See also: Does X-Content-Type-Options really prevent content sniffing attacks?

Also have a look at the OWASP Secure Headers Project for more details on security-relevant headers with some real-life examples.

Community
  • 1
Arminius
  • 43,922
  • 13
  • 140
  • 136
  • 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? – Kevin Fegan Nov 14 '16 at 02:12
  • 4
    @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. – SomeoneSomewhereSupportsMonica Nov 14 '16 at 04:54
  • HTTPS connections do leak the domain name (not just the IP address) because of SNI. There is no need to sniff the DNS traffic. – AKS Nov 14 '16 at 12:59
  • @AyeshK True, since all modern browsers support SNI you don't need to bother with DNS. I'm adding that to the answer. – Arminius Nov 14 '16 at 13:14
  • 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. – Sjoerd Nov 14 '16 at 13:35
  • "the adversary would need to compromise a CA" or get the user to install another CA. – njzk2 Nov 14 '16 at 19:41
  • 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. – Topher Brink Nov 16 '16 at 13:36
  • If HTTP is good enough for stackoverflow, it's good enough for me ;) – Matthew Moisen Nov 17 '16 at 08:16
30
  • HTTPS
  • 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.

user
  • 152
  • 9
Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • What about web application filtering and using a CDN? IMHO those aren't overkill for any web site. – Todd Wilcox Nov 13 '16 at 16:56
  • 2
    @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. – Steffen Ullrich Nov 13 '16 at 17:10
  • 1
    You can still DDoS a static site. – Todd Wilcox Nov 13 '16 at 20:03
  • 1
    @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. – Steffen Ullrich Nov 13 '16 at 20:23
  • 1
    @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. – jpaugh Nov 14 '16 at 01:56
  • 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. – Todd Wilcox Nov 15 '16 at 12:53
5

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:

HTTPS:

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.

HSTS:

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.

CSP:

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.

HPKP:

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.

Clickjacking:

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:

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.

Gunjan Tripathi
  • 166
  • 4
  • 2
    I don't think cookie hijacking, XSS, or clickjacking are applicable to static websites. – Sjoerd Nov 14 '16 at 13:52
  • 1
    I think reflected XSS attacks can be used on sites that run Javascript on the client. I'm not sure if that is part of what the OP is calling static. – bdsl Nov 16 '16 at 13:51
2

this is just my opinion:

  • HTTPS
  • 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.

Community
  • 1
KanekiDev
  • 1,039
  • 6
  • 9
  • 7
    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. – Sjoerd Nov 14 '16 at 13:39
  • 1
    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. – KanekiDev Nov 14 '16 at 14:55
  • 3
    "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. – tomsmeding Nov 14 '16 at 17:26
  • 1
    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. – KanekiDev Nov 15 '16 at 07:09
  • 1
    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 :( – Anthony Geoghegan Nov 15 '16 at 12:38
  • "As there's no possible XSS attack" an attacker could still modify the static files if they had access to them which is a possible attack method – Topher Brink Nov 16 '16 at 13:41