@critiq/rules 0.0.2 → 0.2.0

package/rules/typescript/ts.security.express-reduce-fingerprint.rule.yaml

@@ -5,6 +5,21 @@ metadata:
   title: Reduce Express fingerprinting
   summary: Express apps should disable `x-powered-by` or equivalent fingerprinting headers.
   rationale: Framework fingerprinting gives attackers unnecessary detail about the stack they are targeting.
+  detection:
+    kind: pattern
+  references:
+    - kind: cwe
+      id: CWE-16
+      title: Configuration
+    - kind: owasp
+      title: Secure Configuration Cheat Sheet
+      url: https://cheatsheetseries.owasp.org/cheatsheets/Secure_Configuration_Cheat_Sheet.html
+    - kind: url
+      title: Node.js security best practices
+      url: https://nodejs.org/en/learn/getting-started/security-best-practices
+    - kind: url
+      title: Express production security best practices
+      url: https://expressjs.com/en/advanced/best-practice-security.html
   tags:
     - security
     - express
@@ -35,3 +50,4 @@ emit:
   remediation:
     summary: Disable `x-powered-by` or use equivalent middleware to reduce framework fingerprinting.
 
+

package/rules/typescript/ts.security.express-static-assets-after-session.rule.yaml

@@ -5,6 +5,21 @@ metadata:
   title: Serve static assets before session middleware
   summary: Static assets should be mounted before session middleware when they do not need session state.
   rationale: Serving public assets after session middleware broadens the session surface and adds unnecessary auth-state handling to static traffic.
+  detection:
+    kind: pattern
+  references:
+    - kind: cwe
+      id: CWE-614
+      title: Sensitive Cookie Without Secure Attribute
+    - kind: owasp
+      title: Session Management Cheat Sheet
+      url: https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html
+    - kind: url
+      title: Node.js security best practices
+      url: https://nodejs.org/en/learn/getting-started/security-best-practices
+    - kind: url
+      title: Express production security best practices
+      url: https://expressjs.com/en/advanced/best-practice-security.html
   tags:
     - security
     - express
@@ -35,3 +50,4 @@ emit:
   remediation:
     summary: Mount `express.static()` before session middleware unless the static path genuinely requires session state.
 
+

package/rules/typescript/ts.security.express-static-dotfiles-allow.rule.yaml

@@ -0,0 +1,51 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: ts.security.express-static-dotfiles-allow
+  title: Do not allow dotfiles in Express static middleware
+  summary: express.static should not serve dotfiles from disk unless explicitly required and reviewed.
+  rationale: Allowing dotfiles can expose hidden configuration and secrets through the static file middleware.
+  detection:
+    kind: pattern
+  references:
+    - kind: cwe
+      id: CWE-16
+      title: Configuration
+    - kind: owasp
+      title: Secure Configuration Cheat Sheet
+      url: https://cheatsheetseries.owasp.org/cheatsheets/Secure_Configuration_Cheat_Sheet.html
+    - kind: url
+      title: Node.js security best practices
+      url: https://nodejs.org/en/learn/getting-started/security-best-practices
+    - kind: url
+      title: Express production security best practices
+      url: https://expressjs.com/en/advanced/best-practice-security.html
+  tags:
+    - security
+    - express
+    - filesystem
+    - rules-catalog
+  stability: stable
+  appliesTo: block
+scope:
+  languages:
+    - typescript
+    - javascript
+match:
+  fact:
+    kind: security.express-static-dotfiles-allow
+    bind: issue
+emit:
+  finding:
+    category: security.misconfiguration
+    severity: medium
+    confidence: 0.84
+    tags:
+      - security
+      - express
+  message:
+    title: "Restrict dotfiles for ${captures.issue.text}"
+    summary: "${captures.issue.text} is configured with dotfiles allow, which can leak hidden files."
+  remediation:
+    summary: Use the default dotfiles ignore behavior or serve dotfiles from a tightly scoped directory with access controls.
+

package/rules/typescript/ts.security.express-unbounded-body-parser.rule.yaml

@@ -0,0 +1,50 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: ts.security.express-unbounded-body-parser
+  title: Set explicit Express body parser and multer size limits
+  summary: Express and Body Parser middleware plus Multer should declare explicit payload limits.
+  rationale: Default limits drift across frameworks and deployments; explicit caps reduce oversized-request abuse.
+  detection:
+    kind: pattern
+  references:
+    - kind: cwe
+      id: CWE-16
+      title: Configuration
+    - kind: owasp
+      title: Secure Configuration Cheat Sheet
+      url: https://cheatsheetseries.owasp.org/cheatsheets/Secure_Configuration_Cheat_Sheet.html
+    - kind: url
+      title: Node.js security best practices
+      url: https://nodejs.org/en/learn/getting-started/security-best-practices
+    - kind: url
+      title: Express production security best practices
+      url: https://expressjs.com/en/advanced/best-practice-security.html
+  tags:
+    - security
+    - express
+    - rules-catalog
+  stability: experimental
+  appliesTo: block
+scope:
+  languages:
+    - typescript
+    - javascript
+match:
+  fact:
+    kind: security.express-unbounded-body-parser
+    bind: issue
+emit:
+  finding:
+    category: security.misconfiguration
+    severity: medium
+    confidence: 0.78
+    tags:
+      - security
+      - express
+  message:
+    title: Declare explicit payload limits for body parsers and uploads
+    summary: "`${captures.issue.text}` runs without visible size limits."
+  remediation:
+    summary: Pass `limit` options to JSON/urlencoded/raw/text parsers and `limits.fileSize` (or equivalent) to Multer.
+

package/rules/typescript/ts.security.express-user-controlled-static-mount.rule.yaml

@@ -0,0 +1,51 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: ts.security.express-user-controlled-static-mount
+  title: Avoid request-controlled Express static mount paths
+  summary: The path prefix for express.static should not be derived directly from request objects.
+  rationale: User-controlled mount paths can collapse routing assumptions and expose unintended directories.
+  detection:
+    kind: pattern
+  references:
+    - kind: cwe
+      id: CWE-22
+      title: Path Traversal
+    - kind: owasp
+      title: Path Traversal
+      url: https://owasp.org/www-community/attacks/Path_Traversal
+    - kind: url
+      title: Node.js security best practices
+      url: https://nodejs.org/en/learn/getting-started/security-best-practices
+    - kind: url
+      title: Express production security best practices
+      url: https://expressjs.com/en/advanced/best-practice-security.html
+  tags:
+    - security
+    - express
+    - path
+    - rules-catalog
+  stability: stable
+  appliesTo: block
+scope:
+  languages:
+    - typescript
+    - javascript
+match:
+  fact:
+    kind: security.express-user-controlled-static-mount
+    bind: issue
+emit:
+  finding:
+    category: security.path-traversal
+    severity: high
+    confidence: 0.8
+    tags:
+      - security
+      - express
+  message:
+    title: "Fix static mount path in ${captures.issue.text}"
+    summary: "${captures.issue.text} mounts express.static under a request-derived URL prefix."
+  remediation:
+    summary: Use fixed, reviewed path prefixes and map external identifiers to internal paths through an allowlist.
+

package/rules/typescript/ts.security.external-file-upload.rule.yaml

@@ -5,6 +5,15 @@ metadata:
   title: Do not persist upload filenames directly
   summary: Upload handlers should not store attacker-controlled filenames without generating or validating a safe local name.
   rationale: Upload filenames can carry traversal payloads, collisions, or misleading extensions that break local containment.
+  detection:
+    kind: pattern
+  references:
+    - kind: cwe
+      id: CWE-434
+      title: Unrestricted Upload of File with Dangerous Type
+    - kind: owasp
+      title: File Upload Cheat Sheet
+      url: https://cheatsheetseries.owasp.org/cheatsheets/File_Upload_Cheat_Sheet.html
   tags:
     - security
     - filesystem
@@ -34,3 +43,4 @@ emit:
     summary: "`${captures.issue.text}` persists an upload filename derived from attacker-controlled input."
   remediation:
     summary: Generate a server-side filename or apply a strict allowlist before storing uploaded content.
+

package/rules/typescript/ts.security.fastify-excessive-body-limit.rule.yaml

@@ -0,0 +1,50 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: ts.security.fastify-excessive-body-limit
+  title: Avoid excessive Fastify body limits
+  summary: Fastify applications should not disable body limits or configure unusually large defaults without compensating controls.
+  rationale: Oversized bodies amplify denial-of-service risk on services without upstream buffering limits.
+  detection:
+    kind: pattern
+  references:
+    - kind: cwe
+      id: CWE-16
+      title: Configuration
+    - kind: owasp
+      title: Secure Configuration Cheat Sheet
+      url: https://cheatsheetseries.owasp.org/cheatsheets/Secure_Configuration_Cheat_Sheet.html
+    - kind: url
+      title: Node.js security best practices
+      url: https://nodejs.org/en/learn/getting-started/security-best-practices
+    - kind: url
+      title: Fastify recommendations
+      url: https://fastify.dev/docs/latest/Guides/Recommendation/
+  tags:
+    - security
+    - fastify
+    - rules-catalog
+  stability: experimental
+  appliesTo: block
+scope:
+  languages:
+    - typescript
+    - javascript
+match:
+  fact:
+    kind: security.fastify-excessive-body-limit
+    bind: issue
+emit:
+  finding:
+    category: security.misconfiguration
+    severity: medium
+    confidence: 0.76
+    tags:
+      - security
+      - fastify
+  message:
+    title: Reduce Fastify bodyLimit or add upstream limiting
+    summary: Fastify is configured with an oversized or disabled bodyLimit.
+  remediation:
+    summary: Lower `bodyLimit`, enforce route-specific caps, or terminate traffic behind an API gateway or proxy that caps body size.
+

package/rules/typescript/ts.security.fastify-public-bind-without-trust-proxy.rule.yaml

@@ -0,0 +1,54 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: ts.security.fastify-public-bind-without-trust-proxy
+  title: Enable trust proxy for publicly bound Fastify servers
+  summary: >-
+    Fastify instances listening on all interfaces should enable trustProxy or terminate behind a reverse proxy you register in code.
+  rationale: >-
+    Without trustProxy, client IP and protocol metadata from an edge proxy are easy to misread, and public binds amplify exposure when the process is not intentionally perimeter-hardened.
+  detection:
+    kind: pattern
+  references:
+    - kind: cwe
+      id: CWE-668
+      title: Exposure of Resource to Wrong Sphere
+    - kind: url
+      title: CWE-668 Exposure of Resource to Wrong Sphere
+      url: https://cwe.mitre.org/data/definitions/668.html
+    - kind: url
+      title: Node.js security best practices
+      url: https://nodejs.org/en/learn/getting-started/security-best-practices
+    - kind: url
+      title: Fastify recommendations
+      url: https://fastify.dev/docs/latest/Guides/Recommendation/
+  tags:
+    - security
+    - fastify
+    - rules-catalog
+  stability: experimental
+  appliesTo: block
+scope:
+  languages:
+    - typescript
+    - javascript
+match:
+  fact:
+    kind: security.fastify-public-bind-without-trust-proxy
+    bind: issue
+emit:
+  finding:
+    category: security.misconfiguration
+    severity: medium
+    confidence: 0.74
+    tags:
+      - security
+      - fastify
+  message:
+    title: Set trustProxy or proxy middleware before binding Fastify publicly
+    summary: >-
+      Fastify listens on a public host without trustProxy enabled and without @fastify/http-proxy or @fastify/proxy in this file.
+  remediation:
+    summary: >-
+      Set trustProxy when running behind a reverse proxy, prefer non-public bind addresses in development, or register an explicit Fastify proxy plugin so client metadata and TLS termination assumptions stay correct.
+

package/rules/typescript/ts.security.file-generation.rule.yaml

@@ -5,6 +5,15 @@ metadata:
   title: Constrain local file generation paths
   summary: Local file writes should not derive their destination path from request or upload input.
   rationale: Attacker-controlled write paths can overwrite local state, escape intended directories, or create files in sensitive locations.
+  detection:
+    kind: pattern
+  references:
+    - kind: cwe
+      id: CWE-434
+      title: Unrestricted Upload of File with Dangerous Type
+    - kind: owasp
+      title: File Upload Cheat Sheet
+      url: https://cheatsheetseries.owasp.org/cheatsheets/File_Upload_Cheat_Sheet.html
   tags:
     - security
     - filesystem
@@ -34,3 +43,4 @@ emit:
     summary: "`${captures.issue.text}` writes to a path derived from external input without a trusted local filename."
   remediation:
     summary: Generate the destination name on the server or constrain writes to an allowlisted directory and filename set.
+

package/rules/typescript/ts.security.format-string-using-user-input.rule.yaml

@@ -5,6 +5,15 @@ metadata:
   title: Avoid request-controlled format strings
   summary: Logging and formatting helpers should not take request input as the format string itself.
   rationale: Request-controlled format strings can corrupt logs, leak structure, or produce unexpected formatting behavior.
+  detection:
+    kind: pattern
+  references:
+    - kind: cwe
+      id: CWE-20
+      title: Improper Input Validation
+    - kind: owasp
+      title: Input Validation Cheat Sheet
+      url: https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html
   tags:
     - security
     - logging
@@ -34,3 +43,4 @@ emit:
     summary: "`${captures.issue.text}` uses request-controlled input as the formatting template."
   remediation:
     summary: Keep the format string fixed and pass request data as ordinary arguments or structured fields.
+

package/rules/typescript/ts.security.frontend-only-authorization.rule.yaml

@@ -5,6 +5,15 @@ metadata:
   title: Authorization enforced only on frontend
   summary: Backend routes should enforce authorization directly instead of relying on frontend gating alone.
   rationale: Frontend checks are easy to bypass, so sensitive routes need server-side authorization on the backend path itself.
+  detection:
+    kind: pattern
+  references:
+    - kind: cwe
+      id: CWE-862
+      title: Missing Authorization
+    - kind: owasp
+      title: Authorization Cheat Sheet
+      url: https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html
   tags:
     - security
     - authorization
@@ -33,3 +42,4 @@ emit:
     summary: "Route `${captures.issue.text}` appears gated in frontend code but not on the backend handler."
   remediation:
     summary: Add a backend authorization or permission check on the matching route handler.
+

package/rules/typescript/ts.security.graphql-upload-without-csrf-guard.rule.yaml

@@ -0,0 +1,52 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: ts.security.graphql-upload-without-csrf-guard
+  title: Pair GraphQL multipart uploads with CSRF-safe server posture
+  summary: Legacy GraphQL multipart upload helpers should not run alongside Apollo Server configurations that disable CSRF protections.
+  rationale: Multipart GraphQL requests complicate browser CSRF defenses; when Apollo CSRF prevention is explicitly disabled, upload middleware is a high-risk combination for cross-site writes.
+  detection:
+    kind: pattern
+  references:
+    - kind: cwe
+      id: CWE-434
+      title: Unrestricted Upload of File with Dangerous Type
+    - kind: owasp
+      title: File Upload Cheat Sheet
+      url: https://cheatsheetseries.owasp.org/cheatsheets/File_Upload_Cheat_Sheet.html
+    - kind: url
+      title: Node.js security best practices
+      url: https://nodejs.org/en/learn/getting-started/security-best-practices
+    - kind: url
+      title: Apollo Server security
+      url: https://www.apollographql.com/docs/apollo-server/security/security
+  tags:
+    - security
+    - graphql
+    - rules-catalog
+  stability: experimental
+  appliesTo: block
+scope:
+  languages:
+    - typescript
+    - javascript
+match:
+  fact:
+    kind: security.graphql-upload-without-csrf-guard
+    bind: issue
+emit:
+  finding:
+    category: security.misconfiguration
+    severity: high
+    confidence: 0.8
+    tags:
+      - security
+      - graphql
+  message:
+    title: Re-enable Apollo CSRF defenses or remove GraphQL upload middleware from this bootstrap
+    summary: >-
+      GraphQL upload middleware is registered while Apollo Server disables csrfPrevention, or no Apollo bootstrap with safe CSRF defaults is present.
+  remediation:
+    summary: >-
+      Keep Apollo csrfPrevention enabled (default in supported releases), add an explicit preflight header policy, or move uploads behind authenticated, non-browser APIs.
+

package/rules/typescript/ts.security.handlebars-no-escape.rule.yaml

@@ -5,6 +5,15 @@ metadata:
   title: Keep Handlebars escaping enabled at template trust boundaries
   summary: "Server-side Handlebars compilation should not disable HTML escaping with `noEscape: true`."
   rationale: Disabling Handlebars escaping weakens the template trust boundary and can turn server-rendered output into attacker-controlled HTML.
+  detection:
+    kind: pattern
+  references:
+    - kind: cwe
+      id: CWE-79
+      title: Cross-site Scripting (XSS)
+    - kind: owasp
+      title: Cross Site Scripting Prevention Cheat Sheet
+      url: https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html
   tags:
     - security
     - xss
@@ -36,3 +45,4 @@ emit:
     summary: "`${captures.issue.text}` disables Handlebars escaping at a server-template trust boundary."
   remediation:
     summary: Leave Handlebars escaping enabled, or treat raw HTML rendering as an explicit, narrowly reviewed trust boundary.
+

package/rules/typescript/ts.security.hardcoded-auth-secret.rule.yaml

@@ -5,6 +5,15 @@ metadata:
   title: Avoid hardcoded auth secrets
   summary: JWT, session, and strategy secrets should not be embedded directly in source code.
   rationale: Hardcoded auth secrets are hard to rotate and are exposed whenever the codebase or build artifacts leak.
+  detection:
+    kind: pattern
+  references:
+    - kind: cwe
+      id: CWE-798
+      title: Use of Hard-coded Credentials
+    - kind: owasp
+      title: Secrets Management Cheat Sheet
+      url: https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html
   tags:
     - security
     - authentication
@@ -35,3 +44,4 @@ emit:
   remediation:
     summary: Load the secret from environment-backed configuration or a secret manager and rotate the exposed value.
 
+

package/rules/typescript/ts.security.iframe-missing-sandbox-attribute.rule.yaml

@@ -0,0 +1,45 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: ts.security.iframe-missing-sandbox-attribute
+  title: Add a sandbox attribute to iframes
+  summary: Intrinsic iframe elements should declare a sandbox attribute to reduce blast radius.
+  rationale: Sandboxed iframes limit scripts, forms, and top-level navigation when embedded third-party content is compromised.
+  detection:
+    kind: pattern
+  references:
+    - kind: cwe
+      id: CWE-16
+      title: Configuration
+    - kind: owasp
+      title: Secure Configuration Cheat Sheet
+      url: https://cheatsheetseries.owasp.org/cheatsheets/Secure_Configuration_Cheat_Sheet.html
+  tags:
+    - security
+    - react
+    - xss
+    - rules-catalog
+  stability: stable
+  appliesTo: block
+scope:
+  languages:
+    - typescript
+    - javascript
+match:
+  fact:
+    kind: security.iframe-missing-sandbox-attribute
+    bind: issue
+emit:
+  finding:
+    category: security.misconfiguration
+    severity: low
+    confidence: 0.75
+    tags:
+      - security
+      - react
+  message:
+    title: "Add sandbox to ${captures.issue.text}"
+    summary: "${captures.issue.text} is missing a sandbox attribute."
+  remediation:
+    summary: Add the most restrictive sandbox token set that still allows required behavior, and combine with a strict CSP.
+

package/rules/typescript/ts.security.import-using-user-input.rule.yaml

@@ -5,6 +5,15 @@ metadata:
   title: Constrain module-loading trust boundaries
   summary: "`require()` and dynamic `import()` should not resolve modules from untrusted input."
   rationale: Untrusted module paths let attackers steer module-loading boundaries toward unintended files, packages, or plugins.
+  detection:
+    kind: pattern
+  references:
+    - kind: cwe
+      id: CWE-78
+      title: OS Command Injection
+    - kind: owasp
+      title: OS Command Injection Defense Cheat Sheet
+      url: https://cheatsheetseries.owasp.org/cheatsheets/OS_Command_Injection_Defense_Cheat_Sheet.html
   tags:
     - security
     - execution
@@ -34,3 +43,4 @@ emit:
     summary: "`${captures.issue.text}` crosses a module-loading trust boundary with untrusted input."
   remediation:
     summary: Resolve modules from a fixed allowlist or explicit dispatcher instead of untrusted request or event data.
+

package/rules/typescript/ts.security.information-leakage.rule.yaml

@@ -5,6 +5,15 @@ metadata:
   title: Avoid leaking sensitive or diagnostic state
   summary: Logs, stdout or stderr, and direct response sinks should not expose sensitive fields or internal diagnostic detail.
   rationale: Stack traces, request metadata, auth or session objects, and environment state are often leaked through "temporary" debugging output that later reaches production paths.
+  detection:
+    kind: pattern
+  references:
+    - kind: cwe
+      id: CWE-532
+      title: Insertion of Sensitive Information into Log File
+    - kind: owasp
+      title: Logging Cheat Sheet
+      url: https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html
   tags:
     - security
     - privacy
@@ -36,3 +45,4 @@ emit:
     summary: "`${captures.issue.text}` exposes sensitive fields or internal diagnostic detail through a direct sink."
   remediation:
     summary: Replace the payload with a fixed summary, redact sensitive fields, and strip stack, env, request, or cookie data from production output.
+

package/rules/typescript/ts.security.insecure-allow-origin.rule.yaml

@@ -5,6 +5,15 @@ metadata:
   title: Do not reflect request origin into CORS policy
   summary: "`Access-Control-Allow-Origin` should not be set from request-controlled input."
   rationale: Reflecting the request origin into a CORS allowlist turns origin validation into a no-op.
+  detection:
+    kind: pattern
+  references:
+    - kind: cwe
+      id: CWE-942
+      title: Permissive Cross-domain Policy with Untrusted Domains
+    - kind: owasp
+      title: Cross-Origin Resource Sharing (CORS)
+      url: https://owasp.org/www-community/attacks/CORS_OriginHeaderScrutiny
   tags:
     - security
     - cors
@@ -34,3 +43,4 @@ emit:
     summary: "`${captures.issue.text}` reflects request input into `Access-Control-Allow-Origin`."
   remediation:
     summary: Set CORS origins from a fixed allowlist or explicit trusted origin check.
+

package/rules/typescript/ts.security.insecure-auth-cookie-flags.rule.yaml

@@ -5,6 +5,15 @@ metadata:
   title: Harden auth-bearing cookies
   summary: Auth and session cookies should set HttpOnly, Secure, and SameSite.
   rationale: Cookie flags prevent browser scripts, mixed transport, and cross-site requests from exposing session-bearing values.
+  detection:
+    kind: pattern
+  references:
+    - kind: cwe
+      id: CWE-614
+      title: Sensitive Cookie Without Secure Attribute
+    - kind: owasp
+      title: Session Management Cheat Sheet
+      url: https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html
   tags:
     - security
     - authentication
@@ -35,3 +44,4 @@ emit:
   remediation:
     summary: Add `HttpOnly`, `Secure`, and an explicit `SameSite` policy before the cookie is used for session or auth state.
 
+

package/rules/typescript/ts.security.insecure-content-security-policy-literal.rule.yaml

@@ -0,0 +1,45 @@
+apiVersion: critiq.dev/v1alpha1
+kind: Rule
+metadata:
+  id: ts.security.insecure-content-security-policy-literal
+  title: Avoid unsafe Content-Security-Policy literals
+  summary: Static CSP header values should not rely on unsafe-inline, unsafe-eval, or unsafe-hashes without nonces.
+  rationale: Permissive CSP keywords weaken XSS defenses for every response that carries the header.
+  detection:
+    kind: pattern
+  references:
+    - kind: cwe
+      id: CWE-16
+      title: Configuration
+    - kind: owasp
+      title: Secure Configuration Cheat Sheet
+      url: https://cheatsheetseries.owasp.org/cheatsheets/Secure_Configuration_Cheat_Sheet.html
+  tags:
+    - security
+    - csp
+    - headers
+    - rules-catalog
+  stability: stable
+  appliesTo: block
+scope:
+  languages:
+    - typescript
+    - javascript
+match:
+  fact:
+    kind: security.insecure-content-security-policy-literal
+    bind: issue
+emit:
+  finding:
+    category: security.misconfiguration
+    severity: medium
+    confidence: 0.8
+    tags:
+      - security
+      - csp
+  message:
+    title: "Tighten Content-Security-Policy in ${captures.issue.text}"
+    summary: "${captures.issue.text} sets a CSP that includes unsafe directives without a nonce-based escape hatch."
+  remediation:
+    summary: Prefer nonces or hashes, remove unsafe-inline and unsafe-eval, and scope directives to the smallest required surface.
+