Ok, seems a bit "modern web" focused. My score:
-25 for not defending against Javascript attacks on my javascript free domain
-40 for not forcing HTTPS
-35 more for not protecting against non-existing javascript being manipulated
-25 for not defending against Javascript attacks on my javascript free domain
-40 for not forcing HTTPS
-35 more for not protecting against non-existing javascript being manipulated
For most of the websites out there (that might want to accept user input, or ensure that the page content isn't manipulated or hijacked), that indeed would be a good recommendation.
What would prevent someone from adding a few <script> tags here and there with ads on your site, or code to spy on your users? ISPs have historically already abused this, here's just one example, though you can look up plenty more through your search engine of choice: https://stackoverflow.com/questions/30505416/eliminate-isp-i...
Personally, i really dislike that the web has come to this.
Nothing, probably. In a sane country and legal system doing things like that would be illegal. But on the other hand forcing HTTPS means that some users will never be able access it due to old browsers and/or hardware.
More likely though is that I mess up the HTTPS certificates, either by mistake or inaction, and lock out everyone who doesn't dare click the correct sequence of "ignore warning" buttons.
I've already managed to block access for normal users to several sites, several times, by running too old certbot versions, not integrating things properly and whatnot. It's a good thing I'll never use HSTS and HPKP, or I'll make permanent messes.
Always fun when you lock yourself out of your own website for several days.
It should, but it isn't always the case. Not only that, but even if it is technically illegal, it still might be done because of a lack of people who'll take the guilty parties to court over it. So, in reality, you cannot avoid viewing that as a well founded risk.
> But on the other hand forcing HTTPS means that some users will never be able access it due to old browsers and/or hardware.
In a similar argument about what "should" happen - Google shouldn't just abandon numerous Android devices out there, nor should any other vendor. There should be mechanisms in place to ensure that these devices continue to function for the decades to come.
But since that's not the case, it's inevitable that you'll cut off a small portion of your potential userbase, same as with many sites simply not functioning because the developers made the choice to require JS. Of course, that is your choice, unless other concerns (like security) force your hand.
> More likely though is that I mess up the HTTPS certificates, either by mistake or inaction, and lock out everyone who doesn't dare click the correct sequence of "ignore warning" buttons. I've already managed to block access for normal users to several sites, several times, by running too old certbot versions, not integrating things properly and whatnot. It's a good thing I'll never use HSTS and HPKP, or I'll make permanent messes.
I run a couple of sites through a .dev domain and i do agree with what you're saying, since locking yourself out sooner or later is inevitable, but in my eyes i'd treat it like any other problem out there, much like messing up exposing the correct firewall ports - fix the problem, set up monitoring to be alerted of any problems in the future and move on.
That's why having development/test/staging environments is really useful and in case you fear rate limits, Let's Encrypt also has a staging environment that you can use before switching over to prod: https://letsencrypt.org/docs/staging-environment/
Not only that, but there are a few web servers here and there that attempt to improve the situation with ensuring SSL/TLS, like Traefik. Personally, however, i've found Caddy to be the most painless, since with it i don't need to mess around with integrating certbot with Apache/Nginx, but instead can just use it, since it works out of the box for the most part: https://caddyserver.com/
Apart from that, you can always just expose a version without HTTPS on the server's ports locally, so that you can set up a tunnel through SSH and access it from your device in emergency situations (or just use a self signed certificate for the "private" version).
To be fair, I've done that on my personal site a few times too, and if HTTPS is broken, I consider the site broken (the same as being offline). It's time for fixing it, not for hacking around an HTTP version.
That said, I never cared about HSTS and CSP. Those headers are a joke. The correct way to force HTTPS and certificate verification is on the client, not as a hint by the server. Yeah, I will put them there if I ever bother to customize those webserver settings, there just isn't much of a reason either way.
I agree that HTTPS is more effective than CSP but HSTS addresses the problem of doing that without breaking the web: if you don't have a way for someone typing www.google.com into the browser's location bar or following an old bookmark, you're leaving millions of people vulnerable to potential MITM attacks on the local network. HSTS allows sites to opt-in after they verify everything is working so most traffic is protected long before every antiquated enterprise IT site is updated.