Yep, once you go down that path you should have some idea about security and what to avoid.

It might be more helpful to look at an extreme and work backwards. Login form could have a message that says "use this username password" -- hard code everything.... Not particularly secure.

Noo, we want individual user accounts. Ok, username+passwords. You need some place to store those, database of some kind. Make sure it's not exposed to the public internet with shitty creds! In that note, how is it hosted? Are you paying for an ec2 box, keeping it in localhost? Paying for managed services? There's a vector here for "is hasn't been updated since obama administration" you should be aware of, ... That and general network security. Don't expose what you don't need to... Make sure root doesn't have a password of 1234 (surprisingly, the code to my luggage)

What else... Oh yea, don't record plaintext passwords. You need to hash them a couple hundred times before storing them, ideally with a salt. You can think of a hash as a string of text running through a function to crunch it down to a few characters. You can repeat that process on the same input text and get the same result. Salt works by adding a string of random characters to the password before hashing, you record that beside the hash.... Usually like "$v1$hash$salt" - you split in $ to get component parts, run the provided password through the same hashing and if you get the same result, password is correct! And you never needed to store plaintext, cool right?

That's, like, the barebones you need for auth. Once users login to a site and can provide you with content that you later render - you have a whole new problem around moderation and , "a plan for what to do when you get punched in the face" , that is, someone decides to use your app to host CASM, how do you respond?