eslint-plugin-sdl-2 1.0.4

package/docs/rules/no-child-process-exec.md

@@ -0,0 +1,101 @@
+---
+title: no-child-process-exec
+---
+
+# no-child-process-exec
+
+Disallow `child_process.exec()` and `child_process.execSync()` shell-backed execution APIs.
+
+## Targeted pattern scope
+
+This rule targets `exec()` and `execSync()` when they are imported from
+`child_process` or `node:child_process`, destructured from `require(...)`, or
+called through a namespace binding created from those modules.
+
+## What this rule reports
+
+This rule reports direct use of `child_process.exec()` and
+`child_process.execSync()` because both APIs execute a command string through a
+shell.
+
+## Why this rule exists
+
+Shell-backed command execution is harder to review safely than argv-separated
+process launches. When user-controlled data is concatenated into a command
+string, it can become command injection.
+
+For SDL-oriented code review, `spawn()` and `execFile()` are generally easier
+to reason about because they keep the executable path and the arguments
+separate.
+
+## ❌ Incorrect
+
+```ts
+import { exec } from "node:child_process";
+
+exec(`git show ${userSuppliedRef}`);
+```
+
+```ts
+const { execSync } = require("child_process");
+
+execSync("tar -xf " + archivePath);
+```
+
+```ts
+import * as childProcess from "node:child_process";
+
+childProcess.exec("convert " + inputPath);
+```
+
+## ✅ Correct
+
+```ts
+import { execFile } from "node:child_process";
+
+execFile("git", ["show", userSuppliedRef]);
+```
+
+```ts
+const { spawn } = require("child_process");
+
+spawn("tar", ["-xf", archivePath], { shell: false });
+```
+
+## Behavior and migration notes
+
+This rule intentionally focuses on direct `child_process` bindings and does not
+attempt to reason about custom wrapper utilities that may call `exec()`
+internally.
+
+## ESLint flat config example
+
+```ts
+import sdl from "eslint-plugin-sdl-2";
+
+export default [
+ {
+  plugins: { sdl },
+  rules: {
+   "sdl/no-child-process-exec": "error",
+  },
+ },
+];
+```
+
+## When not to use it
+
+If your project intentionally permits shell-backed command execution and you
+already review all command construction paths carefully, this rule may be too
+strict.
+
+## Package documentation
+
+- [Rule source](../../src/rules/no-child-process-exec.ts)
+
+## Further reading
+
+> **Rule catalog ID:** R062
+
+- [Node.js child\_process documentation](https://nodejs.org/api/child_process.html)
+- [OWASP Command Injection](https://owasp.org/www-community/attacks/Command_Injection)

package/docs/rules/no-child-process-shell-true.md

@@ -0,0 +1,59 @@
+# no-child-process-shell-true
+
+Disallow Node child process options that enable `shell: true`.
+
+## Targeted pattern scope
+
+Node child\_process execution options that enable `shell: true`.
+
+## What this rule reports
+
+`spawn(...)` / `execFile(...)` options objects with `shell: true`.
+
+## Why this rule exists
+
+Shell execution expands injection risk when command fragments include user-influenced input.
+
+## ❌ Incorrect
+
+```ts
+spawn("cmd", ["/c", command], { shell: true });
+```
+
+## ✅ Correct
+
+```ts
+spawn("node", ["script.js"], { shell: false });
+```
+
+## ESLint flat config example
+
+```ts
+import sdl from "eslint-plugin-sdl-2";
+
+export default [
+ {
+  plugins: { sdl },
+
+  rules: {
+   "sdl/no-child-process-shell-true": "error",
+  },
+ },
+];
+```
+
+## When not to use it
+
+Disable only when shell execution is unavoidable and all command fragments are strictly controlled and validated.
+
+## Package documentation
+
+- [Rule source](../../src/rules/no-child-process-shell-true.ts)
+
+## Further reading
+
+> **Rule catalog ID:** R032
+
+- [OWASP Top 10: Injection](https://owasp.org/www-project-top-ten/)
+
+- [OWASP Top 10: Security Misconfiguration](https://owasp.org/www-project-top-ten/)

package/docs/rules/no-cookies.md

@@ -0,0 +1,61 @@
+# no-cookies
+
+Disallow client-side cookie usage patterns that increase session and data risk.
+
+## Targeted pattern scope
+
+This rule targets browser cookie read and write patterns, including direct
+access to `document.cookie`.
+
+## What this rule reports
+
+This rule reports cookie usage in client code where safer or less exposed
+storage patterns are preferred.
+
+## Why this rule exists
+
+Cookies are frequently sent over network requests and can expand leakage and
+tampering risk when misconfigured.
+
+## ❌ Incorrect
+
+```ts
+document.cookie = `sessionToken=${token}; path=/`;
+```
+
+## ✅ Correct
+
+```ts
+localStorage.setItem("sessionToken", token);
+```
+
+## ESLint flat config example
+
+```ts
+import sdl from "eslint-plugin-sdl-2";
+
+export default [
+ {
+  plugins: { sdl },
+  rules: {
+   "sdl/no-cookies": "error",
+  },
+ },
+];
+```
+
+## When not to use it
+
+Disable this rule when application requirements mandate cookie-backed sessions
+with hardened attributes and server controls.
+
+## Package documentation
+
+- [Rule source](../../src/rules/no-cookies.ts)
+
+## Further reading
+
+> **Rule catalog ID:** R006
+
+- [MDN: Using HTTP cookies](https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies)
+- [Legacy rule inspiration](https://github.com/microsoft/tslint-microsoft-contrib/blob/master/src/noCookiesRule.ts)

package/docs/rules/no-document-domain.md

@@ -0,0 +1,59 @@
+# no-document-domain
+
+Disallow writes to `document.domain` that weaken same-origin boundaries.
+
+## Targeted pattern scope
+
+This rule targets assignments that modify `document.domain`.
+
+## What this rule reports
+
+This rule reports any direct write to `document.domain`.
+
+## Why this rule exists
+
+Changing `document.domain` can relax origin checks and create cross-origin trust
+relationships that were not intended.
+
+## ❌ Incorrect
+
+```ts
+document.domain = "example.com";
+```
+
+## ✅ Correct
+
+```ts
+// Keep default browser origin boundaries.
+```
+
+## ESLint flat config example
+
+```ts
+import sdl from "eslint-plugin-sdl-2";
+
+export default [
+ {
+  plugins: { sdl },
+  rules: {
+   "sdl/no-document-domain": "error",
+  },
+ },
+];
+```
+
+## When not to use it
+
+Disable only for vetted legacy integrations that cannot be migrated away from
+`document.domain`.
+
+## Package documentation
+
+- [Rule source](../../src/rules/no-document-domain.ts)
+
+## Further reading
+
+> **Rule catalog ID:** R007
+
+- [MDN: `document.domain`](https://developer.mozilla.org/en-US/docs/Web/API/Document/domain)
+- [MDN: Same-origin policy](https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy#changing_origin)

package/docs/rules/no-document-execcommand-insert-html.md

@@ -0,0 +1,69 @@
+# no-document-execcommand-insert-html
+
+Disallow `document.execCommand("insertHTML", ...)` HTML insertion sinks.
+
+## Targeted pattern scope
+
+This rule targets `Document.execCommand(...)` calls when the command name is the
+static string `insertHTML` and the inserted value is non-empty.
+
+## What this rule reports
+
+This rule reports `document.execCommand("insertHTML", false, html)` style calls
+because that command inserts markup into the current selection or editing host.
+
+## Why this rule exists
+
+`execCommand("insertHTML", ...)` is an HTML sink. When the inserted markup comes
+from untrusted or weakly reviewed input, it can create XSS exposure in rich-text
+editors and other editable surfaces.
+
+## ❌ Incorrect
+
+```ts
+document.execCommand("insertHTML", false, userHtml);
+```
+
+## ✅ Correct
+
+```ts
+document.execCommand("insertText", false, userText);
+```
+
+## Behavior and migration notes
+
+This rule intentionally focuses only on the `insertHTML` command and ignores
+other `execCommand(...)` usages such as `copy` or `bold`. Empty string
+insertions are also ignored to keep the rule narrow and low-noise.
+
+## ESLint flat config example
+
+```ts
+import sdl from "eslint-plugin-sdl-2";
+
+export default [
+ {
+  plugins: { sdl },
+  rules: {
+   "sdl/no-document-execcommand-insert-html": "error",
+  },
+ },
+];
+```
+
+## When not to use it
+
+Disable this rule only if your editor pipeline has a reviewed requirement to
+insert trusted HTML through `execCommand("insertHTML", ...)` and that trust
+boundary is documented.
+
+## Package documentation
+
+- [Rule source](../../src/rules/no-document-execcommand-insert-html.ts)
+
+## Further reading
+
+> **Rule catalog ID:** R060
+
+- [MDN: `Document.execCommand()`](https://developer.mozilla.org/en-US/docs/Web/API/Document/execCommand)
+- [OWASP Cross Site Scripting Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html)

package/docs/rules/no-document-parse-html-unsafe.md

@@ -0,0 +1,72 @@
+# no-document-parse-html-unsafe
+
+Disallow `Document.parseHTMLUnsafe()` calls that parse HTML through the unsafe document-construction path.
+
+## Targeted pattern scope
+
+This rule targets direct `Document.parseHTMLUnsafe(...)` calls, including
+`window.Document.parseHTMLUnsafe(...)` and `globalThis.Document.parseHTMLUnsafe(...)`.
+
+## What this rule reports
+
+This rule reports `Document.parseHTMLUnsafe(...)` because that API name is the
+explicit unsafe parsing path for creating a new `Document` from HTML.
+
+## Why this rule exists
+
+`Document.parseHTMLUnsafe()` does not guarantee that XSS-unsafe markup will be
+removed. That makes it a poor default for application code that handles HTML
+input, especially when a safer `Document.parseHTML()` path or a reviewed
+sanitization pipeline is available.
+
+## ❌ Incorrect
+
+```ts
+const parsed = Document.parseHTMLUnsafe(userHtml);
+```
+
+## ✅ Correct
+
+```ts
+const parsed = Document.parseHTML(userHtml);
+```
+
+## Behavior and migration notes
+
+This rule intentionally reports the unsafe API itself instead of trying to infer
+whether an optional sanitizer argument is strong enough. If you truly need the
+unsafe API for a reviewed edge case, disable the rule locally and document that
+trust boundary.
+
+## ESLint flat config example
+
+```ts
+import sdl from "eslint-plugin-sdl-2";
+
+export default [
+ {
+  plugins: { sdl },
+  rules: {
+   "sdl/no-document-parse-html-unsafe": "error",
+  },
+ },
+];
+```
+
+## When not to use it
+
+Disable only if your codebase has a reviewed requirement to use
+`Document.parseHTMLUnsafe()` and that call site is already protected by a
+sanitization policy this rule cannot verify.
+
+## Package documentation
+
+- [Rule source](../../src/rules/no-document-parse-html-unsafe.ts)
+
+## Further reading
+
+> **Rule catalog ID:** R056
+
+- [MDN: `Document.parseHTMLUnsafe()`](https://developer.mozilla.org/en-US/docs/Web/API/Document/parseHTMLUnsafe_static)
+- [MDN: `Document.parseHTML()`](https://developer.mozilla.org/en-US/docs/Web/API/Document/parseHTML_static)
+- [Trusted Types API](https://developer.mozilla.org/en-US/docs/Web/API/Trusted_Types_API)

package/docs/rules/no-document-write.md

@@ -0,0 +1,64 @@
+# no-document-write
+
+Disallow direct DOM writes through `document.write` and `document.writeln`.
+
+## Targeted pattern scope
+
+This rule targets:
+
+- `document.write(...)`
+- `document.writeln(...)`.
+
+## What this rule reports
+
+This rule reports direct document stream writes that inject HTML into the page.
+
+## Why this rule exists
+
+`document.write` APIs are prone to injection and can overwrite document state in
+unpredictable ways.
+
+## ❌ Incorrect
+
+```ts
+document.write(`<div>${userInput}</div>`);
+```
+
+## ✅ Correct
+
+```ts
+const node = document.createElement("div");
+node.textContent = userInput;
+document.body.append(node);
+```
+
+## ESLint flat config example
+
+```ts
+import sdl from "eslint-plugin-sdl-2";
+
+export default [
+ {
+  plugins: { sdl },
+  rules: {
+   "sdl/no-document-write": "error",
+  },
+ },
+];
+```
+
+## When not to use it
+
+Disable only in controlled legacy rendering flows that cannot migrate from
+document stream writes.
+
+## Package documentation
+
+- [Rule source](../../src/rules/no-document-write.ts)
+
+## Further reading
+
+> **Rule catalog ID:** R008
+
+- [MDN: `document.write`](https://developer.mozilla.org/en-US/docs/Web/API/Document/write)
+- [Legacy rule inspiration](https://github.com/microsoft/tslint-microsoft-contrib/blob/master/src/noDocumentWriteRule.ts)

package/docs/rules/no-domparser-html-without-sanitization.md

@@ -0,0 +1,59 @@
+# no-domparser-html-without-sanitization
+
+Disallow `DOMParser.parseFromString(..., "text/html")` on unsanitized input.
+
+## Targeted pattern scope
+
+`DOMParser.parseFromString(..., "text/html")` on unsanitized input.
+
+## What this rule reports
+
+HTML parsing calls where the source value is not sanitized by an explicit policy function.
+
+## Why this rule exists
+
+Parsing unsanitized HTML creates unsafe document fragments and XSS surfaces.
+
+## ❌ Incorrect
+
+```ts
+new DOMParser().parseFromString(userHtml, "text/html");
+```
+
+## ✅ Correct
+
+```ts
+new DOMParser().parseFromString(sanitize(userHtml), "text/html");
+```
+
+## ESLint flat config example
+
+```ts
+import sdl from "eslint-plugin-sdl-2";
+
+export default [
+ {
+  plugins: { sdl },
+
+  rules: {
+   "sdl/no-domparser-html-without-sanitization": "error",
+  },
+ },
+];
+```
+
+## When not to use it
+
+Disable only if the parsed HTML is produced by a reviewed sanitizer or a fully trusted template source.
+
+## Package documentation
+
+- [Rule source](../../src/rules/no-domparser-html-without-sanitization.ts)
+
+## Further reading
+
+> **Rule catalog ID:** R033
+
+- [OWASP Top 10: Injection](https://owasp.org/www-project-top-ten/)
+
+- [OWASP Top 10: Security Misconfiguration](https://owasp.org/www-project-top-ten/)

package/docs/rules/no-domparser-svg-without-sanitization.md

@@ -0,0 +1,71 @@
+---
+title: no-domparser-svg-without-sanitization
+---
+
+# no-domparser-svg-without-sanitization
+
+Disallow `DOMParser.parseFromString(..., "image/svg+xml")` on unsanitized input.
+
+## Targeted pattern scope
+
+This rule targets `DOMParser.parseFromString(...)` when the MIME type is the
+static string `"image/svg+xml"` and the source value is not passed through an
+explicit sanitizer or trusted-policy helper.
+
+## What this rule reports
+
+This rule reports SVG parsing calls where the input is not sanitized first.
+
+## Why this rule exists
+
+SVG content can carry active content such as event handlers, script-adjacent
+behavior, and external references. Parsing unsanitized SVG into a document can
+create risky DOM fragments that are difficult to review safely.
+
+## ❌ Incorrect
+
+```ts
+new DOMParser().parseFromString(userSvg, "image/svg+xml");
+```
+
+## ✅ Correct
+
+```ts
+new DOMParser().parseFromString(sanitize(userSvg), "image/svg+xml");
+```
+
+## Behavior and migration notes
+
+This rule intentionally focuses on the explicit SVG parsing sink. It does not
+attempt to prove whether a non-matching helper name is actually safe.
+
+## ESLint flat config example
+
+```ts
+import sdl from "eslint-plugin-sdl-2";
+
+export default [
+ {
+  plugins: { sdl },
+  rules: {
+   "sdl/no-domparser-svg-without-sanitization": "error",
+  },
+ },
+];
+```
+
+## When not to use it
+
+Disable this rule only if the parsed SVG always comes from a reviewed sanitizer
+or a fully trusted source and that guarantee is documented.
+
+## Package documentation
+
+- [Rule source](../../src/rules/no-domparser-svg-without-sanitization.ts)
+
+## Further reading
+
+> **Rule catalog ID:** R066
+
+- [MDN: `DOMParser.parseFromString()`](https://developer.mozilla.org/en-US/docs/Web/API/DOMParser/parseFromString)
+- [OWASP SVG Security Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/SVG_Security_Cheat_Sheet.html)

package/docs/rules/no-dynamic-import-unsafe-url.md

@@ -0,0 +1,81 @@
+---
+title: no-dynamic-import-unsafe-url
+---
+
+# no-dynamic-import-unsafe-url
+
+Disallow dynamic `import()` calls that load code from `data:`, `blob:`, `javascript:`, and direct `URL.createObjectURL(...)` URLs.
+
+## Targeted pattern scope
+
+This rule targets direct `import(...)` expressions when the module specifier is
+one of the following executable URL forms:
+
+- a static `data:` URL
+- a static `blob:` URL
+- a static `javascript:` URL
+- a direct `URL.createObjectURL(...)` call
+
+## What this rule reports
+
+This rule reports only direct unsafe dynamic-import specifiers. Indirect
+variables and broader module-resolution policies are out of scope.
+
+## Why this rule exists
+
+Dynamic `import()` is an executable module-loading sink. Loading modules from
+inline, generated, or review-hostile URLs makes trusted code boundaries harder
+to audit and can undermine SDL expectations around reviewed module sources.
+
+## ❌ Incorrect
+
+```ts
+await import("data:text/javascript,export default run()");
+```
+
+```ts
+await import(URL.createObjectURL(workerBlob));
+```
+
+## ✅ Correct
+
+```ts
+await import("./feature-module.js");
+```
+
+## Behavior and migration notes
+
+This rule intentionally focuses on direct unsafe script URL expressions in
+`import(...)`. Indirect variables, import maps, and broader policy enforcement
+are out of scope.
+
+## ESLint flat config example
+
+```ts
+import sdl from "eslint-plugin-sdl-2";
+
+export default [
+ {
+  plugins: { sdl },
+  rules: {
+   "sdl/no-dynamic-import-unsafe-url": "error",
+  },
+ },
+];
+```
+
+## When not to use it
+
+Disable this rule only if your project intentionally relies on these dynamic
+module-loading patterns and that design has been reviewed and approved.
+
+## Package documentation
+
+- [Rule source](../../src/rules/no-dynamic-import-unsafe-url.ts)
+
+## Further reading
+
+> **Rule catalog ID:** R070
+
+- [MDN: `import()`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/import)
+- [Trusted Types: injection sinks](https://developer.mozilla.org/en-US/docs/Web/API/Trusted_Types_API)