Admin permissions with cookies

Hi.I’m building a portfolio website using express.js . The idea is that there will be no user accounts, but I want to make the admin able to manage the content(add projects, edit them, delete them). So I made a login page with only a password as input(the admin’s password).After submission the server should create a session cookie which will be present in every page(there will be just a few of them) .

The question is how secure that approach is ? Are there any other ways to handle this problem ? I would really like to know how would you do this.


The main security issue with cookies is CSRF (Cross Site Request Forgery), but it can be prevented.

Start by using express-session and helmet (this is mentioned in the Information Security and QA course), which will allow you to protect your site against some attacks.

Now, since you’ll be the only user of the site (this is what I understood, at least, sorry if it’s not the case), you should not worry too much.

What you’ll need:

  • Passport, for local authentication (unless you have created your own method).
  • express-session, the package used to create the sessions and serializing the data.
  • cors, to enable CORS.
  • helmetjs, to improve the security of your site.

If your portfolio requests user data (a contact form, for instance), anywhere, then you should use HTTPS (you should use it anyway, since you’ll have an admin login). HTTPS encrypts the data sent and received from the server, otherwise your password (and other sensitive information) will be transmitted in plain text. Let’s Encrypt provides free SSL certificates :slight_smile:!

If you have a contact form, then add a Google Recaptcha to prevent spam. And do not publish your email address on the website (unless it’s an image), otherwise spammers will skip the contact form and read your email address instead.

I think that should do it :stuck_out_tongue:. Hope it helps :slight_smile:!

Happy coding!

1 Like

Thank you, Nicolas for your answer. I implemented the functionality I wanted, but I have one question. As noted in express-session’s docs

The default server-side session storage, MemoryStore , is purposely not designed for a production environment. It will leak memory under most conditions, does not scale past a single process, and is meant for debugging and developing.

It then points to a list of compatible session stores.So my question is if it’s a good idea to use one of those(i’ll definitely go for connect-mongo if I have to) considering that I’m using express-session for a single session cookie which when activated(by submitting a password in a form) notes that the user is an administrator and is destroyed after closing the browser(thus, no expire date) ? No other uses of cookies planned or implemented.Just this one.I’m not sure if not using session stores is secure, because indeed it’s noted that it’ll leak memory under most conditions, but the cookie will be stored server-side.But adding a store will increase the complexity of the project.That’s my dilemma.

PS: I did not use passport though, and cors, as I don’t need them.But will definitely look into helmetJS.

Anyway, thank you again for your help.

Yes, you should. Using sessions is easier than, let’s say, implementing JWT.

It will add complexity, but not too much (depending on the store of choice). For instance, there is session-file-storage, which (as the name implies) stores the sessions on the file system, which may be easier to implement than one that relies on mongo (or connect-mongo).

That said, you could implement a Basic Authentication scheme, where you would define the user/password in a static manner. See express-basic-auth for more information. It’s insecure (plain text user/password defined on the server), but you can add some security by using process.env to define the user/password.

You could also keep a backup of your database (you should have two, with the current and previous changes, for instance) and project files (these, I suppose, you already have–github, gitlab, bitbucket, etc.). That way, if an attacker manages to get access to your database, you can start from scratch with your latest backup.

These are the options I can think of, but are not the only ones… so, keep looking and let us know if you use something else :slight_smile: (so we can learn too),

Happy coding!