@critiq/rules 0.0.2 → 0.1.0

package/README.md

@@ -40,14 +40,48 @@ Run against a diff:
 npx critiq check . --base origin/main --head HEAD
 ```
 
+## GitHub Actions
+
+For pull request workflows that run `critiq check` in CI and want to post **inline review comments** on the pr, use the Github Action **[critiq-dev/critiq-action](https://github.com/critiq-dev/critiq-action)** ([README](https://github.com/critiq-dev/critiq-action/blob/main/README.md)). It installs `@critiq/cli` (and `@critiq/rules` when needed), respects `.critiq/config.yaml`, and does not require Critiq Cloud or a separate account.
+
+Example `.github/workflows/critiq.yml`:
+
+```yaml
+name: Critiq Review
+
+on:
+  pull_request:
+
+permissions:
+  contents: read
+  pull-requests: write
+
+jobs:
+  critiq:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v6
+        with:
+          fetch-depth: 0
+
+      - name: Run Critiq
+        uses: critiq-dev/critiq-action@v1
+        with:
+          fail-on-severity: off
+```
+
+Use a **major tag** (`@v1`) or pin a **commit SHA** for supply-chain control. More options (inputs, outputs, monorepos, reusable workflow) are in the [action README](https://github.com/critiq-dev/critiq-action/blob/main/README.md).
+
 ## Catalog At A Glance
 
-Today the catalog includes `112` rules across `10` categories, with `recommended`, `strict`, `security`, and `experimental` presets.
+Today the catalog includes `309` rules across `17` categories, with `recommended`, `strict`, `security`, and `experimental` presets.
 
 | Category | Rules | What it looks after |
 | --- | ---: | --- |
-| Security | 70 | Injection, auth and session gaps, unsafe transport, sensitive data exposure, unsafe file and HTML handling |
-| Correctness | 15 | Async bugs, null access, control-flow mistakes, missing fallbacks, race conditions |
+| Security | 93 | Injection, auth and session gaps, unsafe transport, sensitive data exposure, dependency policy, unsafe file and HTML handling |
+| Python | 9 | Django, DRF, Flask, and FastAPI deployment and framework safety |
+| Correctness | 18 | Async bugs, null access, control-flow mistakes, missing fallbacks, race conditions |
 | Performance | 10 | Repeated IO, wasted async sequencing, hot-path loops, large retained objects, render churn |
 | Quality | 10 | Error handling gaps, oversized functions, coupling, duplicated logic, and weak test coverage |
 | Logging | 2 | Console usage and unsafe logging patterns |
@@ -85,7 +119,7 @@ Critiq keeps the OSS catalog intentionally high-signal.
 
 ## More Rules In This Catalog
 
-The catalog also includes these `100` additional rules beyond the highlights above.
+The catalog also includes these `165` additional rules beyond the highlights above.
 
 ### Security
 
@@ -142,6 +176,8 @@ The catalog also includes these `100` additional rules beyond the highlights abo
 | `Avoid leaking sensitive or diagnostic state` | Logs, stdout or stderr, and direct response sinks should not expose sensitive fields or internal diagnostic detail. |
 | `Do not derive anti-framing headers from request input` | Framing and CSP headers should not be set from request-controlled values. |
 | `Avoid request-controlled format strings` | Logging and formatting helpers should not take request input as the format string itself. |
+| `Sanitize user-controlled values before they reach log messages` | Logger calls in pino, winston, bunyan, and consola should not interpolate or concatenate request input directly into the message text. |
+| `Remove leftover console.trace calls from production paths` | `console.trace()` calls should not ship in production code outside an explicit dev-only branch. |
 | `` Constrain `res.sendFile` to a trusted root `` | `res.sendFile()` should not resolve filenames or options from request input without a trusted root. |
 | `` Constrain `res.render()` trust boundaries `` | Express view names should not cross into server-side rendering from untrusted input. |
 | `Avoid exposed directory listings` | Directory listing middleware should not be enabled on public paths without a deliberate review. |
@@ -149,6 +185,18 @@ The catalog also includes these `100` additional rules beyond the highlights abo
 | `Override Express cookie defaults` | Express session cookie settings should not omit explicit lifetime, scope, and transport attributes. |
 | `Avoid permissive Express session cookie scope` | Express session cookies should not explicitly opt into cross-site or wildcard-style scope. |
 | `Serve static assets before session middleware` | Static assets should be mounted before session middleware when they do not need session state. |
+| `Limit Express request parser body size` | Express and body-parser middleware should set explicit parser limits, including upload middleware caps. |
+| `Constrain Fastify body limits` | Fastify bootstrap and route-level body limits should not be disabled or set unusually high without compensating controls. |
+| `Protect Fastify public bind posture` | Fastify public binds should pair with trust-proxy or gateway controls before exposing upstream network metadata. |
+| `Harden Apollo GraphQL CSRF posture` | Apollo server configs should not disable CSRF protection in public bootstraps. |
+| `Constrain Apollo introspection exposure` | Apollo production bootstraps should not unconditionally enable introspection. |
+| `Require GraphQL query limiting controls` | Public GraphQL servers should define depth, complexity, persisted operation, or equivalent query limiting controls. |
+| `Avoid Apollo dev tooling exposure in production` | Apollo dev landing pages and playground plugins should not ship without explicit production guards. |
+| `Avoid GraphQL upload middleware without CSRF guard` | GraphQL multipart upload middleware should not run when CSRF prevention is explicitly disabled. |
+| `Apply Helmet before NestJS route mounts` | NestJS apps should register helmet before route middleware mounts. |
+| `Enable NestJS global validation pipe` | NestJS bootstraps should configure a global ValidationPipe to harden DTO trust boundaries. |
+| `Whitelist NestJS ValidationPipe payload fields` | ValidationPipe should enable whitelist-style filtering for request payload hardening. |
+| `Avoid SkipThrottle on sensitive NestJS auth routes` | Sensitive NestJS auth routes should not bypass throttle controls without compensating protection. |
 | `Apply Helmet to Express apps` | Express apps should use Helmet or equivalent header hardening middleware. |
 | `Reduce Express fingerprinting` | Express apps should disable `x-powered-by` or equivalent fingerprinting headers. |
 | `Do not expose debug routes or middleware in production` | Debug handlers, stack-showing middleware, and diagnostic endpoints should stay behind explicit development-only guards. |