Which security measures make sense for a static web site?

Question

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
• Strict transport security
• Content security policy
• Certificate pinning
• Clickjacking protection
• Content sniffing protection

Answer 1

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.

Answer 2

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

Answer 3

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.

Answer 4

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.