docs: add lint-time security checks section to security best practices

Adds a short section on static analysis to the Production Best Practices:
Security page. It complements the existing runtime protections and
dependency scanning advice by covering lint-time detection of insecure
patterns (hardcoded secrets, unsafe redirects, missing cookie flags,
injection-prone string building).

Resolves #2471

Signed-off-by: METHILA M <260591810+methila-2056@users.noreply.github.com>

Author: methila-2056

src/content/pages/en/advanced/best-practice-security.mdx

@@ -31,6 +31,7 @@ Security best practices for Express applications in production include:
 - [Prevent brute-force attacks against authorization](#prevent-brute-force-attacks-against-authorization)
 - [Ensure your dependencies are secure](#ensure-your-dependencies-are-secure)
   - [Avoid other known vulnerabilities](#avoid-other-known-vulnerabilities)
+- [Lint your code for security issues](#lint-your-code-for-security-issues)
 - [Additional considerations](#additional-considerations)
 
 ## Don't use deprecated or vulnerable versions of Express
@@ -304,6 +305,19 @@ Keep an eye out for [GitHub Advisory Database](https://github.com/advisories?que
 
 Finally, Express apps—like any other web apps—can be vulnerable to a variety of web-based attacks. Familiarize yourself with known [web vulnerabilities](https://owasp.org/www-project-top-ten/) and take precautions to avoid them.
 
+## Lint your code for security issues
+
+Dependency scanning (as described above) checks the packages you install, but not the code you write. Static analysis tools catch insecure code patterns at lint time—before the code ships—such as:
+
+- Hardcoded secrets and credentials in source code
+- Unsafe redirects (see [Prevent open redirects](#prevent-open-redirects))
+- Missing cookie security flags (see [Use cookies securely](#use-cookies-securely))
+- Injection-prone string building for SQL queries or shell commands
+
+Most Express apps already run [ESLint](https://eslint.org/) for code quality, and several ESLint plugins add security-focused rules on top of it. Run these checks in CI alongside your tests so that new violations fail the build.
+
+Static analysis complements, but does not replace, the runtime protections described on this page, such as Helmet and dependency scanning.
+
 ## Additional considerations
 
 Here are some further recommendations from the excellent [Node.js Security Checklist](https://blog.risingstack.com/node-js-security-checklist/). Refer to that blog post for all the details on these recommendations: