Of course, thanks to all the dev.to folks that chime in on these kinds of threads. This kind of willing wisdom sharing is such a big part of what makes the dev.to community special. 😇
Regarding prepared statements. Look into what your driver does with them.
Some drivers just concatenate the strings (no protection at all), others do a sanitised concatenation, the best send it to the server to compile and then send the parameters to the server in separate calls (best).
Know what your driver does! Don't assume.
(Also don't rely on this mechanism.. CHECK YOUR INPUTS!)
These are great. Here is my 2-cents to add to your list:
This has some good overlap with your items and a few others to add:
Web Developer Security Checklist: dev.to/powerdowncloud/web-develope...
Would be a good to point out essential maturity of security development.
What are your thoughts about access-controlled documentation and restricting libraries with known vulnerabilities (CVEs)?
Thanks for posting this. I learned a lot, and the Darkwing Duck image just about triples the credibility of the advice here.
4. Assume user input is malicious until proven otherwise.
Corollary: You cannot prove a negative as in "not malicious".
The secure apps or Web is no code. Seriously: github.com/kelseyhightower/nocode
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.