eslint-plugin-sdl-2 1.0.4

package/docs/rules/no-msapp-exec-unsafe.md

@@ -0,0 +1,59 @@
+# no-msapp-exec-unsafe
+
+Disallow `MSApp.execUnsafeLocalFunction` calls that bypass script safety checks.
+
+## Targeted pattern scope
+
+This rule targets `MSApp.execUnsafeLocalFunction(...)` usage.
+
+## What this rule reports
+
+This rule reports direct calls to unsafe local function execution wrappers.
+
+## Why this rule exists
+
+This API bypasses platform script injection protections and can allow unsafe DOM
+or script execution.
+
+## ❌ Incorrect
+
+```ts
+MSApp.execUnsafeLocalFunction(() => {
+ element.innerHTML = userSuppliedHtml;
+});
+```
+
+## ✅ Correct
+
+```ts
+element.textContent = userSuppliedHtml;
+```
+
+## ESLint flat config example
+
+```ts
+import sdl from "eslint-plugin-sdl-2";
+
+export default [
+ {
+  plugins: { sdl },
+  rules: {
+   "sdl/no-msapp-exec-unsafe": "error",
+  },
+ },
+];
+```
+
+## When not to use it
+
+Disable only for legacy Windows Store app code that is isolated and audited.
+
+## Package documentation
+
+- [Rule source](../../src/rules/no-msapp-exec-unsafe.ts)
+
+## Further reading
+
+> **Rule catalog ID:** R022
+
+- [Microsoft documentation: `MSApp.execUnsafeLocalFunction`](https://learn.microsoft.com/en-us/previous-versions/windows/apps/hh780593\(v=win.10\))

package/docs/rules/no-node-tls-check-server-identity-bypass.md

@@ -0,0 +1,88 @@
+# no-node-tls-check-server-identity-bypass
+
+Disallow Node.js `checkServerIdentity` overrides that always accept the peer hostname.
+
+## Targeted pattern scope
+
+This rule targets Node.js TLS/HTTPS/http2 option objects, plus assignments to
+`tls.checkServerIdentity`, when the configured callback always succeeds by:
+
+- using an empty function body
+- returning `undefined`
+- returning `null`
+- returning `void ...`
+
+## What this rule reports
+
+This rule reports `checkServerIdentity` implementations that suppress hostname
+verification instead of delegating to `tls.checkServerIdentity(...)` or a
+reviewed stronger verification path.
+
+## Why this rule exists
+
+Overriding `checkServerIdentity` is a security-sensitive escape hatch. A
+callback that always returns success disables hostname validation and can allow
+connections to certificates that do not match the expected server identity.
+
+## ❌ Incorrect
+
+```ts
+import https from "node:https";
+import tls from "node:tls";
+
+https.request({
+ checkServerIdentity() {},
+});
+
+tls.checkServerIdentity = () => undefined;
+```
+
+## ✅ Correct
+
+```ts
+import https from "node:https";
+import tls from "node:tls";
+
+https.request({
+ checkServerIdentity(hostname, cert) {
+  return tls.checkServerIdentity(hostname, cert);
+ },
+});
+```
+
+## Behavior and migration notes
+
+This rule intentionally reports only specific unsafe callback shapes. More
+complex certificate pinning or hostname validation logic is not analyzed.
+
+## ESLint flat config example
+
+```ts
+import sdl from "eslint-plugin-sdl-2";
+
+export default [
+ {
+  plugins: { sdl },
+  rules: {
+   "sdl/no-node-tls-check-server-identity-bypass": "error",
+  },
+ },
+];
+```
+
+## When not to use it
+
+Disable this rule only if your codebase has a reviewed custom
+`checkServerIdentity` implementation and this rule's narrow syntactic heuristic
+still flags that approved pattern.
+
+## Package documentation
+
+- [Rule source](../../src/rules/no-node-tls-check-server-identity-bypass.ts)
+
+## Further reading
+
+> **Rule catalog ID:** R061
+
+- [Node.js TLS documentation: `checkServerIdentity`](https://nodejs.org/api/tls.html#tlscheckserveridentityhostname-cert)
+- [OWASP Transport Layer Security Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Security_Cheat_Sheet.html)

package/docs/rules/no-node-tls-legacy-protocol.md

@@ -0,0 +1,80 @@
+# no-node-tls-legacy-protocol
+
+Disallow legacy TLS protocol selection in Node.js TLS and HTTPS configuration.
+
+## Targeted pattern scope
+
+This rule targets Node.js TLS and HTTPS option objects, plus assignments to
+`tls.DEFAULT_MIN_VERSION` or `tls.DEFAULT_MAX_VERSION`, when they select legacy
+protocols such as `TLSv1`, `TLSv1.0`, `TLSv1.1`, or legacy
+`secureProtocol` values like `TLSv1_method`.
+
+## What this rule reports
+
+This rule reports legacy protocol selection through:
+
+- `minVersion`
+- `maxVersion`
+- `secureProtocol`
+- `tls.DEFAULT_MIN_VERSION`
+- `tls.DEFAULT_MAX_VERSION`
+
+## Why this rule exists
+
+Allowing TLS 1.0 or TLS 1.1 weakens transport security and can re-enable
+obsolete protocol negotiation for outbound or inbound connections. Modern Node
+code should require TLS 1.2 or newer.
+
+## ❌ Incorrect
+
+```ts
+import tls from "node:tls";
+import https from "node:https";
+
+tls.createSecureContext({ minVersion: "TLSv1.1" });
+new https.Agent({ secureProtocol: "TLSv1_method" });
+tls.DEFAULT_MIN_VERSION = "TLSv1";
+```
+
+## ✅ Correct
+
+```ts
+import tls from "node:tls";
+import https from "node:https";
+
+tls.createSecureContext({ minVersion: "TLSv1.2" });
+new https.Agent({ secureProtocol: "TLSv1_2_method" });
+tls.DEFAULT_MIN_VERSION = "TLSv1.2";
+```
+
+## ESLint flat config example
+
+```ts
+import sdl from "eslint-plugin-sdl-2";
+
+export default [
+ {
+  plugins: { sdl },
+  rules: {
+   "sdl/no-node-tls-legacy-protocol": "error",
+  },
+ },
+];
+```
+
+## When not to use it
+
+Disable this rule only if you intentionally maintain legacy interoperability
+with endpoints that cannot support TLS 1.2 or newer, and that compatibility
+decision is documented and explicitly accepted as risk.
+
+## Package documentation
+
+- [Rule source](../../src/rules/no-node-tls-legacy-protocol.ts)
+
+## Further reading
+
+> **Rule catalog ID:** R058
+
+- [Node.js TLS documentation](https://nodejs.org/api/tls.html)
+- [OWASP Transport Layer Security Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Security_Cheat_Sheet.html)

package/docs/rules/no-node-tls-reject-unauthorized-zero.md

@@ -0,0 +1,61 @@
+# no-node-tls-reject-unauthorized-zero
+
+Disallow `process.env.NODE_TLS_REJECT_UNAUTHORIZED = "0"` in Node.js code.
+
+## Targeted pattern scope
+
+This rule targets assignment expressions that set
+`process.env.NODE_TLS_REJECT_UNAUTHORIZED` to `0` or `"0"`.
+
+## What this rule reports
+
+This rule reports assignments that disable TLS certificate verification through
+`NODE_TLS_REJECT_UNAUTHORIZED`.
+
+## Why this rule exists
+
+Disabling certificate validation removes server identity verification and
+introduces man-in-the-middle risk for outbound TLS connections.
+
+## ❌ Incorrect
+
+```ts
+process.env.NODE_TLS_REJECT_UNAUTHORIZED = "0";
+```
+
+## ✅ Correct
+
+```ts
+process.env.NODE_TLS_REJECT_UNAUTHORIZED = "1";
+```
+
+## ESLint flat config example
+
+```ts
+import sdl from "eslint-plugin-sdl-2";
+
+export default [
+ {
+  plugins: { sdl },
+  rules: {
+   "sdl/no-node-tls-reject-unauthorized-zero": "error",
+  },
+ },
+];
+```
+
+## When not to use it
+
+Disable only in tightly controlled local debugging contexts where no production
+or shared environment can inherit the override.
+
+## Package documentation
+
+- [Rule source](../../src/rules/no-node-tls-reject-unauthorized-zero.ts)
+
+## Further reading
+
+> **Rule catalog ID:** R023
+
+- [Node.js environment variables](https://nodejs.org/api/cli.html#environment-variables)
+- [OWASP Transport Layer Security Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Security_Cheat_Sheet.html)

package/docs/rules/no-node-tls-security-level-zero.md

@@ -0,0 +1,77 @@
+# no-node-tls-security-level-zero
+
+Disallow lowering Node.js TLS cipher security to OpenSSL security level `0`.
+
+## Targeted pattern scope
+
+This rule targets Node.js TLS and HTTPS option objects, plus assignments to
+`tls.DEFAULT_CIPHERS`, when the configured cipher string explicitly lowers the
+OpenSSL security level to `@SECLEVEL=0`.
+
+## What this rule reports
+
+This rule reports TLS cipher configuration through:
+
+- `ciphers`
+- `tls.DEFAULT_CIPHERS`
+
+when the configured string contains `@SECLEVEL=0`.
+
+## Why this rule exists
+
+Lowering the OpenSSL security level to `0` weakens the TLS handshake policy and
+can re-enable deprecated or unsafe cipher negotiation behavior. Node's default
+TLS cipher policy is safer than explicitly downgrading to security level `0`.
+
+## ❌ Incorrect
+
+```ts
+import https from "node:https";
+import tls from "node:tls";
+
+tls.createSecureContext({ ciphers: "DEFAULT@SECLEVEL=0" });
+new https.Agent({ ciphers: "DEFAULT:@SECLEVEL=0" });
+tls.DEFAULT_CIPHERS = "DEFAULT@SECLEVEL=0";
+```
+
+## ✅ Correct
+
+```ts
+import https from "node:https";
+import tls from "node:tls";
+
+tls.createSecureContext({ ciphers: "DEFAULT" });
+new https.Agent({ ciphers: "DEFAULT" });
+tls.DEFAULT_CIPHERS = "DEFAULT";
+```
+
+## ESLint flat config example
+
+```ts
+import sdl from "eslint-plugin-sdl-2";
+
+export default [
+ {
+  plugins: { sdl },
+  rules: {
+   "sdl/no-node-tls-security-level-zero": "error",
+  },
+ },
+];
+```
+
+## When not to use it
+
+Disable this rule only if you intentionally accept the risk of lowering OpenSSL
+security policy for a documented legacy interoperability requirement.
+
+## Package documentation
+
+- [Rule source](../../src/rules/no-node-tls-security-level-zero.ts)
+
+## Further reading
+
+> **Rule catalog ID:** R059
+
+- [Node.js TLS documentation](https://nodejs.org/api/tls.html)
+- [OWASP Transport Layer Security Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Security_Cheat_Sheet.html)

package/docs/rules/no-node-vm-run-in-context.md

@@ -0,0 +1,89 @@
+---
+title: no-node-vm-run-in-context
+---
+
+# no-node-vm-run-in-context
+
+Disallow `node:vm` dynamic code execution APIs that are commonly mistaken for a security sandbox.
+
+## Targeted pattern scope
+
+This rule targets `node:vm` and `vm` imports or `require(...)` bindings when
+code is executed through:
+
+- `runInNewContext(...)`
+- `runInContext(...)`
+- `runInThisContext(...)`
+- `compileFunction(...)`
+- `new Script(...)`
+
+## What this rule reports
+
+This rule reports direct use of the `vm` module's code-execution APIs because
+those APIs compile or execute JavaScript source text.
+
+## Why this rule exists
+
+Node's own documentation warns that the `vm` module is not a security
+mechanism. Teams sometimes treat it like a safe sandbox for untrusted code, but
+that assumption is fragile and can lead to code execution or sandbox-escape
+exposure.
+
+## ❌ Incorrect
+
+```ts
+import vm from "node:vm";
+
+vm.runInNewContext(userCode, sandbox);
+```
+
+```ts
+const { Script } = require("vm");
+
+new Script(untrustedSource);
+```
+
+## ✅ Correct
+
+```ts
+import vm from "node:vm";
+
+vm.measureMemory();
+```
+
+## Behavior and migration notes
+
+This rule intentionally focuses on the `vm` module's code-execution entry
+points. It does not attempt to determine whether a specific source string is
+trusted.
+
+## ESLint flat config example
+
+```ts
+import sdl from "eslint-plugin-sdl-2";
+
+export default [
+ {
+  plugins: { sdl },
+  rules: {
+   "sdl/no-node-vm-run-in-context": "error",
+  },
+ },
+];
+```
+
+## When not to use it
+
+Disable this rule only if your project has a reviewed and documented reason to
+use `node:vm` code-execution APIs and that risk is accepted explicitly.
+
+## Package documentation
+
+- [Rule source](../../src/rules/no-node-vm-run-in-context.ts)
+
+## Further reading
+
+> **Rule catalog ID:** R064
+
+- [Node.js documentation: `node:vm`](https://nodejs.org/api/vm.html)
+- [Node.js documentation note: The `node:vm` module is not a security mechanism](https://nodejs.org/api/vm.html)

package/docs/rules/no-node-vm-source-text-module.md

@@ -0,0 +1,79 @@
+---
+title: no-node-vm-source-text-module
+---
+
+# no-node-vm-source-text-module
+
+Disallow `node:vm` `SourceTextModule` constructors that compile JavaScript source strings into executable modules.
+
+## Targeted pattern scope
+
+This rule targets `SourceTextModule` constructors imported from `node:vm` or
+`vm`.
+
+The rule covers:
+
+- named imports like `import { SourceTextModule } from "node:vm"`
+- namespace/default bindings like `vm.SourceTextModule`
+- CommonJS `require(...)` destructuring and namespace access
+
+## What this rule reports
+
+This rule reports `new SourceTextModule(...)` for the Node `vm` module.
+
+## Why this rule exists
+
+`SourceTextModule` compiles JavaScript module source from a string. Like other
+`node:vm` code-loading APIs, it is easy to mistake this for a security boundary
+when it is really an executable code sink that deserves explicit SDL review.
+
+## ❌ Incorrect
+
+```ts
+import { SourceTextModule } from "node:vm";
+
+new SourceTextModule(userSuppliedModuleCode);
+```
+
+## ✅ Correct
+
+```ts
+await import(new URL("./module.js", import.meta.url).href);
+```
+
+## Behavior and migration notes
+
+This rule intentionally focuses on `SourceTextModule` construction through the
+Node `vm` module. It does not attempt to determine whether a specific source
+string is trusted.
+
+## ESLint flat config example
+
+```ts
+import sdl from "eslint-plugin-sdl-2";
+
+export default [
+ {
+  plugins: { sdl },
+  rules: {
+   "sdl/no-node-vm-source-text-module": "error",
+  },
+ },
+];
+```
+
+## When not to use it
+
+Disable this rule only if your project intentionally relies on `SourceTextModule`
+and that design has been reviewed and approved.
+
+## Package documentation
+
+- [Rule source](../../src/rules/no-node-vm-source-text-module.ts)
+
+## Further reading
+
+> **Rule catalog ID:** R071
+
+- [Node.js: `vm.SourceTextModule`](https://nodejs.org/api/vm.html)
+- [CWE-94: Improper Control of Generation of Code](https://cwe.mitre.org/data/definitions/94.html)

package/docs/rules/no-node-worker-threads-eval.md

@@ -0,0 +1,82 @@
+---
+title: no-node-worker-threads-eval
+---
+
+# no-node-worker-threads-eval
+
+Disallow `node:worker_threads` `Worker` options that enable `eval: true` string execution.
+
+## Targeted pattern scope
+
+This rule targets `Worker` constructors imported from `node:worker_threads` or
+`worker_threads` when the options object contains `eval: true`.
+
+The rule covers:
+
+- named imports like `import { Worker } from "node:worker_threads"`
+- namespace/default bindings like `workerThreads.Worker`
+- CommonJS `require(...)` destructuring and namespace access
+
+## What this rule reports
+
+This rule reports `new Worker(..., { eval: true })` for Node worker threads.
+
+## Why this rule exists
+
+`eval: true` changes the first `Worker` argument from a reviewed script path to
+an executable code string. That makes worker startup behave more like `eval()`
+or `new Function(...)`, which is harder to review safely and can blur trust
+boundaries around code execution.
+
+## ❌ Incorrect
+
+```ts
+import { Worker } from "node:worker_threads";
+
+new Worker(userSuppliedCode, { eval: true });
+```
+
+## ✅ Correct
+
+```ts
+import { Worker } from "node:worker_threads";
+
+new Worker(new URL("./worker.js", import.meta.url));
+```
+
+## Behavior and migration notes
+
+This rule intentionally focuses on inline options objects with `eval: true` for
+worker-thread constructors imported from the Node worker threads module.
+Indirect options variables are out of scope.
+
+## ESLint flat config example
+
+```ts
+import sdl from "eslint-plugin-sdl-2";
+
+export default [
+ {
+  plugins: { sdl },
+  rules: {
+   "sdl/no-node-worker-threads-eval": "error",
+  },
+ },
+];
+```
+
+## When not to use it
+
+Disable this rule only if your project intentionally relies on string-backed
+worker-thread execution and that design has been reviewed and approved.
+
+## Package documentation
+
+- [Rule source](../../src/rules/no-node-worker-threads-eval.ts)
+
+## Further reading
+
+> **Rule catalog ID:** R068
+
+- [Node.js: `worker_threads` `Worker` constructor](https://nodejs.org/api/worker_threads.html)
+- [CWE-94: Improper Control of Generation of Code](https://cwe.mitre.org/data/definitions/94.html)

package/docs/rules/no-nonnull-assertion-on-security-input.md

@@ -0,0 +1,59 @@
+# no-nonnull-assertion-on-security-input
+
+Disallow TypeScript non-null assertions on likely security-sensitive input values.
+
+## Targeted pattern scope
+
+TypeScript non-null assertions on security-sensitive input values.
+
+## What this rule reports
+
+TS non-null assertions on identifiers/properties with security-sensitive names.
+
+## Why this rule exists
+
+Non-null assertions can hide validation gaps and bypass defensive checks on attacker-controlled input.
+
+## ❌ Incorrect
+
+```ts
+const safe = userInput!;
+```
+
+## ✅ Correct
+
+```ts
+const safe = validateInput(userInput);
+```
+
+## ESLint flat config example
+
+```ts
+import sdl from "eslint-plugin-sdl-2";
+
+export default [
+ {
+  plugins: { sdl },
+
+  rules: {
+   "sdl/no-nonnull-assertion-on-security-input": "error",
+  },
+ },
+];
+```
+
+## When not to use it
+
+Disable only if the value has already been validated by a reviewed guard that this rule cannot statically recognize.
+
+## Package documentation
+
+- [Rule source](../../src/rules/no-nonnull-assertion-on-security-input.ts)
+
+## Further reading
+
+> **Rule catalog ID:** R043
+
+- [OWASP Top 10: Injection](https://owasp.org/www-project-top-ten/)
+
+- [OWASP Top 10: Security Misconfiguration](https://owasp.org/www-project-top-ten/)