NodeJS "security".
Recommendations:
1) Don't. Just don't.
2) See point 1, it's important.
3) Maybe transpile Rust into WASM instead?
</snark>
Recommendations:
1) Don't. Just don't.
2) See point 1, it's important.
3) Maybe transpile Rust into WASM instead?
</snark>
Most of these are fundamental server side web app best practice that we learnt decades ago and used Perl libraries that mitigated them back in the 90s.
"Validate your inputs", "escape your outputs", "have good logging", "have brute force protection", "use anti CSRF tokens", "take care parsing http headers" - those are all bits of advice you could find in the comp.lang.perl.misc archives from the late '90s. None of them are NodeJS specific, they're all "inexperienced backend developer" specific bits of advice.
Which is scary...
The main recommendations that I didn't know was request size limits - though I'll probably set the limit in ngnix.
Can I very very strongly recommend, that if this site does any collection of PII or handles payments (even if those are 3rd party ones using something like Stripe), that you get a trusted and experienced dev to do a review for you?
You acknowledge you have unknown unknowns, you must also realise that there are people out there (quite likely people you count as friends) who's space of unknown unknown in the web platform security area is smaller than yours.
There are many unexpected things you likely haven't considered. Where I am, IP addresses are not on their own considered PII, but email addresses are. Somewhat less expectedly though, is that IP addresses that can be linked to another piece of PII then become PII themselves, so if you have a database with an email address and, say, a signup or last login timestamp, suddenly all your web server logs full of IP addresses, request paths (which can identify signups/logins), and timestamps - become linkable via the timestamp/request path to users logging in and their email address in the db, and suddenly the log files become PII with all the duty of disclosure around breaches. (And that's without even considering super common rookie mistakes where PII gets written out win clear text to access or error logs on purpose for debugging reasons.)
My goal was to be more secure than an out of date wordpress site - which I think I have achieved.
I don't really understand the harm that can come from an email/password/ip leak, besides spam or stolen accounts if they reuse their password. Do you have a link that might impress the seriousness of the situation on me?
It is your responsibility as a product owner to protect users from their own security worst-practices. This is true everywhere, but it's especially true in software development. For better or worse, many people reuse passwords. It's not a great idea, but they don't deserve to have their lives upended because someone decided that it's their own fault for not being savvier.
If you don't have any friends that can help then you will likely have to pay someone. "Security engineer" is a job after all.
For HN audience, It sure sounds very old knowledge but for some document intended as cheat sheet / checklist it has place.
I've had a shortened CS education (2yrs) but I'm mostly self taught outside of that. I'm just starting to do a bit more back-end development and I have the exact same issue with these courses; they focus on "build the cool thing using these popular tools" but never on build it right. I don't really care about the shiny new thing personally, I'm looking for fundamentals.
Owasp is a really great resource, just don't concentrate only on a quick Node-related cheat sheet (even if you are using node for your backend). The more generic information handout web application security is very good, and will benefit your knowledge across all languages and frameworks, if you care to consume it.
(There may be genuinely good current resources to learn web app and platform security from, but I cut my teeth there in the late 90s - including fucking up and needing to clean ups after myself, which sadly is the most powerful learning tool, while also being a very very poor way to achieve that learning...)
Have you heard of this shiny new thing, called printed out books?
This is mainly how I learned them.
Saves you some screen time as a bonus.
Yup.
Reminding everybody you need to have some adults in the room.
If your full stack web team has not one single person who's experienced enough to have ever had to investigate and clean up after an intrusion, its 1) going to happen soon, and 2) its going to go badly.
I mean, sure - bootcamp "grads" are cheap and plentiful and have pretty portfolios. But almost none of them should have root on production servers...
Question them even more if you think a smart person wrote them.
(Yep. I've made that mistake often enough to believe that advice.)