Web security basics

Last Update: 2023-04-16

This article covers a few of the basics, that are required for a secure connection and what types of attacks could be prevented using them. These are only a few of many other security measures.

Basic basics

HTTPS - TLS

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 built-in passwords.

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

If used: It will be found

Authentication

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 up-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

Example:

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, ECMAScript) can come from.

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

Example:

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

X-Frame-Options: DENY

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

Example:

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 a XSS attack on your website (or on other websites).

Example:

X-Content-Type-Options: nosniff

Cookies

As cookies are used for authentication, they should be protected properly.

HttpOnly

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

Secure

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

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