The Production Best Practices: Security page currently covers runtime protections (Helmet, secure cookies, rate limiting) and dependency scanning (npm audit, Snyk), but doesn't mention static analysis — catching insecure code patterns (hardcoded secrets, unsafe redirects, missing cookie flags, injection-prone string building) at lint time, before the code ships. Most Express apps already run ESLint, so this is usually a one-dependency addition for readers, and it complements the page's existing advice rather than replacing any of it.
Would a short subsection (or a bullet under "Additional considerations") along the lines of "lint your code for security issues" be welcome? I'm happy to write the PR if so.
Full disclosure: I maintain two MIT-licensed ESLint plugins in this space — eslint-plugin-express-security (Express-specific: insecure cookie settings, missing security headers, CORS misconfigurations) and eslint-plugin-node-security (general Node security rules). They're young projects with modest adoption, so I'd understand if the TC prefers to keep any mention tool-neutral or to name more established options — the suggestion stands either way, and I'll write whatever framing you're comfortable with.
CONTRIBUTING.md asks for an issue first on significant changes, so opening this rather than sending a PR cold.
The Production Best Practices: Security page currently covers runtime protections (Helmet, secure cookies, rate limiting) and dependency scanning (
npm audit, Snyk), but doesn't mention static analysis — catching insecure code patterns (hardcoded secrets, unsafe redirects, missing cookie flags, injection-prone string building) at lint time, before the code ships. Most Express apps already run ESLint, so this is usually a one-dependency addition for readers, and it complements the page's existing advice rather than replacing any of it.Would a short subsection (or a bullet under "Additional considerations") along the lines of "lint your code for security issues" be welcome? I'm happy to write the PR if so.
Full disclosure: I maintain two MIT-licensed ESLint plugins in this space — eslint-plugin-express-security (Express-specific: insecure cookie settings, missing security headers, CORS misconfigurations) and eslint-plugin-node-security (general Node security rules). They're young projects with modest adoption, so I'd understand if the TC prefers to keep any mention tool-neutral or to name more established options — the suggestion stands either way, and I'll write whatever framing you're comfortable with.
CONTRIBUTING.md asks for an issue first on significant changes, so opening this rather than sending a PR cold.