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.
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)
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
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
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: default-src 'self'
Do not allow your website to be included as an iframe in another webpage.
Do not allow sniffing (check the
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
on your website or on other websites.
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).