← Home

Web security basics

By Fionn Langhans

In this article a few of the basics of what is required for a secure connection and what are types of attack are prevented. These are only a few of many other security measures.

Basic basics


End-to-end encryption between the server and the client using public-key cryptography.

Certificates can be aquired without hassle with Let's Encrypt.

If not used: plaintext can be read (e.g. MITM attack)

No standard passwords

Even if you want to easily administer the website (of a client), do not ever use standard or buildin passwords.

If you must have a somewhat secure standard login, use public-key cryptography.

If used: Reddit will find you


As sad as it is, somehow (nodejs) backend developers love to forget this.

If not used: PR is much more important than basic security, right?

And yes, authentication is always one of the hardest parts to do right but completely forgetting it, cannot be excused

Password hashing

Hash every password you can hash and DO NOT store the cleartext password.

If not used: An attacker with access to the database, can immediatly misuse the user logins

Keep your password hashing algorithms update-to-date, don't use md5

Strict Transport Security (HSTS)

HSTS Informs the client that the site should only be accessed using HTTPS. Even when a link to the website uses the http:// schema, the client automatically uses https:// instead.

This should be in the section Basic basics, but reality is sadly different.

If not used: Even if the server always forwards to HTTPs traffic, an attacker can force a regression attack, forcing the client to communicate with plaintext


Strict-Transport-Security: max-age=63072000; includeSubDomains;
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload;

Content Security Policy (CSP)

Restricts where resources (e.g. images, iframes, JavaScript) can come from.

If not used: Attackers could - if the Content-Security-Policy does not exist or is not restrictive enogh - use an XSS attack, if they successfully inject HTML or JavaScript-Code into your webpage.


Content-Security-Policy: default-src 'self'

X-Frame-Options: DENY

Do not allow your website to be included as an iframe in another webpage.

X-Frame-Options: DENY

X-Content-Type-Options: nosniff

Do not allow sniffing (check the Content-Type).

If not used: An attacker could potentially use an upload form on your website and include malicious code in .js. This could also be combined with XSS attack on your website or on other websites.

X-Content-Type-Options: nosniff



If true, then the cookie cannot be read with JavaScript.


If Secure is true, the client forces cookies to be only transmitted with HTTPS.

If not used: If an attack can force a connection with HTTP (e.g. custom links) the cookie can be read. In older browsers the cookie could be overwritten with an insecure cookie by the client, if the server does not check for this, the cookie could still be read, even if it was initially Secure.


SameSite can restrict the cookie to the first-party (current domain).