It is important to view knowledge as sort of a semantic tree — make sure you
understand the fundamental principles, ie the trunk and big branches, before
you get into the leaves/details or there is nothing for them to hang on to.

Elon Musk

The computer scientist Donald Knuth was struck that “AI has by now succeeded
in doing essentially everything that requires ‘thinking’ but has failed to
do most of what people and animals do ‘without thinking’—that, somehow, is
much harder!

You can't try to treat IT guys like they're a constricted cog in the normal
bureaucratic flow of company. The more you try to punish them and make them
conform the less they'll be willing to go above and beyond for you or the
company. You have to communicate with IT guys like they're boys at play. What
they do can get extremely complicated and infuriatingly frustrating, but they
do it because they enjoy it. If you take the joy out of their work then you
take away the creative efforts that they would otherwise put into their
projects.

When you do things right, people won't be sure you've done anything at all.

Futurama s03e20

Purpose

This domain is a technical demo of the latest (security) practices for the web. And my hobby...

This domain implements all of the mentioned security features mentioned below. Feel free
to inspect the implementation and if you find issues or have questions, my contact
information is at the end of the page.

If you think for a second, what do you type in your address bar when you go to
your bank, is it the full url with https://? no, noone does
that, you'd type arionbanki.is or similar. Bookmarked? How did
you make the bookmark?

Without HSTS the browser will then do a simple unencrypted HTTP request which
is easily intercepted by any MITM and
he then owns the entire connection and is able to say anything he wants to the
client.
For example, instead of redirecting the user to HTTPS, just connect himself to
the HTTPS page and proxy it to the user over HTTP, intercepting anything he
wants or even injecting his own date into requests, the sky is the limit.

With HSTS, when the browser receives a request for HTTP on a HSTS protected
domain, it will issue a Status Code: 307 Internal Redirect
that never reaches the server or opens any connection to the HTTP version of
the link, the user is protected without even noticing and is suddenly on
a HTTPS encrypted connection.

An issue is the first request, the user is not protected until he gets the
header over a valid HTTPS connection, which is what preloading is for, it
is a signal that allows browser vendors to include a domain with the HSTS
flag already set in browser updates, protecting the first request too. But
it applies to entire domains and all subdomains so companies are nervous
to implement it.

A major benefit is that this signal indicates to browsers that this domain must
always be loaded securely and it allows them to REMOVE the "proceed anyway"
method that oh so many users just click blindly without reading. You can
see that in action here.

Do you have random CSS and JavaScript all over the place, maybe even inside
your HTML directly, bad news, you are very probably vulnurable to XSS.

CSP lets you whitelist sources of images, scripts and styles, it blocks all
"unsafe-inline" styles and scripts by default and allows you to make user
browsers report when those whitelists are violated when they block those
resources.

Implementing CSP is more than just flicking a switch like HSTS, you need to know
your application pretty well, using inline styles or scripts is out of the
question, eval is completely dead, so is insertRule and more unsafe stuff.

After loading that once, you'll see that it blocks literally everything,
that policy even blocks your favicon, so start with finding out where it is
loaded, on your domain? Cool, add a img-src 'self'; and move on
to the next, repeat until no blocks remain.

If you need unsafe-* policies, that's fine, just be aware of
them and make it a goal of limiting it as much as possible and make an
internal ticket to fix that issue!

Whenever you include CSS or JavaScript in your page, you point it to a link and
pray it loads correctly and has no malware or cryptocoin miners or similar, right?

Well, if you use SRI, you can be assured that only the file you specified gets
loaded and if it fails, you can either just block it, breaking that resource,
or fall back on a known safe file on your local server!

That is exactly why SRI was created, to be able to include resources without
having to trust the third party too much.
You still have to trust that he isn't tracking your users, but that's what
privacy policies and privacy laws are for, right?

DNSSEC is a way to sign your DNS zone so that your users can receive
information from DNS and be able to verify that the records received are
really from your dns and not some attack.

The biggest challenge in getting DNSSEC is software, both your
authoritative DNS server needs to serve it correctly but users are not
protected by it unless their resolver also verify the DNSSEC information.

The Online Certificate Status Protocol is a method of checking whether a
certificate has been revoked, but due to scaling problems with the ever
increasing amount of HTTPS everywhere, they all implement a soft-fail on
pretty much all errors, and some clients don't even bother checking at all
so they introduced OCSP Stapling where the server serving the certificate
includes a signed OCSP signature from the CA along with the certificate
itself.

Now that's great, the client verifies it and life is good, but if the key
ever gets stolen, then the thief can just, not send the stapled OCSP
response to clients and they are none the viser.

That's where must-staple comes in, it is a field in the certificate that
states that stapling is mandatory and skipping it is never okay.