feat: add CodeQL GitHub Actions workflow

[sherryhli]

Ticket link

Closes #142

Implementation description

Steps to test

What should reviewers focus on?

Checklist

• My PR name is descriptive and in imperative tense
• My commit messages are descriptive and in imperative tense. My commits are atomic and trivial commits are squashed or fixup'd into non-trivial commits
• I have run the appropriate linter(s)
• I have requested a review from the PL, as well as other devs who have background knowledge on this PR or who will be building on top of this PR

[alexguo8]

Marking the "Clear text storage of sensitive information" as won't-fix

• We set the cookies to Secure in production so they are encrypted anyways, didn't really find anything online suggesting that the value should also be encrypted inside the encrypted cookie

[alexguo8]

Marking the "Database query built from user-controlled sources" as false positive

• the error page suggests using features from the database connector library to embed values, but doesn't seem like mongoose has these
• most advice online is about sanitizing input before it reaches the mongoose code, and we validate the request body as soon as it is received before running the findByIdAndUpdate
• not sure why only the update is flagged and not the create endpoint as well

[alexguo8]

Looked into the "Missing CSRF middleware" alert

• A CSRF attack occurs when an attacker submits a state-change request (POST, DELETE, PUT, etc) for an authenticated user by using the user's cookie (once they click on a malicious URL)
• Using the csurf package we can implement the "double submit cookie" solution,
• As a summary, at the beginning of a session, the server sends back a CSRF token as a cookie (done by csurf) and in a second way (done by us). Then on an API request, the clients also sends the second CSRF token to the server (as a header/hidden form field, NOT as a cookie) and the server checks that it matches with the first CSRF token in the cookie (more details here)
• An attacker could only send the first CSRF token in the cookie (since the second one has to be sent in the request as a header/form field), so there would not be a match and it would fail
• I don't see it being too hard to implement but there are some tricky implementation decisions (note we have to find equivalent in python too if we add this):
• Where can we store the second CSRF token in the frontend before it is used in a request? (I've only seem examples of csurf using server side rendering where the second token is embedded into the returned page)
• When should we send back the CSRF token? (if on login, then a user leaving the site and coming back would still be logged in but wouldn't hit the login endpoint I believe, so they wouldn't get the token) (if on every request, then things like back buttons on the browser wouldn't work since old requests had outdated tokens)

[alexguo8]

Marking "Uncontrolled data used in path expression" as won't-fix

• Files are uploaded to the dest folder specified by multer, so the req.file.path is supplied by multer (and not directly by the user)
• Couldn't find any articles online mentioning a multer file path vulnerability
• Concerns for this are that users can access other files on the system using a path like ../ (path traversal attack), but slashes are not allowed in file names so req.file.path should just be uploads/{filename} (let me know if I'm wrong about this)