torusguard 1.0.0 → 1.3.1

package/.torusguard/rules/TG-CLIENT-001-public-production-source-maps.md

@@ -0,0 +1,102 @@
+# TG-CLIENT-001: Public Production Source Maps
+
+## Severity
+
+Medium
+
+## Applies To
+
+- Vite production builds (`build.sourcemap`)
+- Next.js production source map settings (`productionBrowserSourceMaps`)
+- Create React App/Webpack production `devtool` configuration
+- Static hosting/CDN configurations that publish `.map` assets publicly
+- Any SPA/SSR frontend bundle served to untrusted clients
+
+## Why It Matters
+
+Source maps improve debugging, but can expose internal implementation details.
+Public `.map` files make reverse engineering easier at scale.
+Attackers can quickly recover original symbols, comments, and code structure.
+This increases the efficiency of finding hidden routes, feature flags, and weak points.
+It does not create a vulnerability alone, but it lowers attacker effort materially.
+Browser DevTools cannot be blocked, so exposure must be reduced at build and hosting layers.
+
+## What TorusGuard Looks For
+
+- Build configs enabling source maps for production bundles
+- Presence of emitted `*.js.map` or `*.css.map` in deploy artifacts
+- CDN/static host rules that allow unauthenticated access to map files
+- Missing split behavior (private error telemetry maps vs public maps)
+- Framework defaults overridden to expose maps in production
+- CI pipelines that upload maps to public artifact locations
+
+## Unsafe Example
+
+```ts
+// vite.config.ts
+import { defineConfig } from "vite";
+
+export default defineConfig({
+  build: {
+    sourcemap: true
+  }
+});
+```
+
+```js
+// next.config.js
+module.exports = {
+  productionBrowserSourceMaps: true
+};
+```
+
+## Safe Example
+
+```ts
+// vite.config.ts
+import { defineConfig } from "vite";
+
+export default defineConfig({
+  build: {
+    sourcemap: false
+  }
+});
+```
+
+```js
+// next.config.js
+module.exports = {
+  productionBrowserSourceMaps: false
+};
+```
+
+## Remediation
+
+1. Disable public production source maps by default in Vite/Next/CRA/Webpack.
+2. If stack-trace symbolication is required, upload maps to a private error-monitoring service only.
+3. Block direct `.map` retrieval on CDN and static hosting layers.
+4. Validate build pipelines do not copy maps into public deployment folders.
+5. Remove already published map files from current and prior versions where feasible.
+6. Document an exception process for temporary debugging in production.
+7. Pair with bundle scanning to ensure sensitive literals are not shipped regardless.
+
+## Verification
+
+- Build production artifacts and confirm no `*.map` files in public output.
+- Request known map paths in deployed environments and verify denial/404 behavior.
+- Check framework configs (`vite.config`, `next.config`, webpack overrides) for safe values.
+- Confirm telemetry symbolication still works via private upload channels where used.
+- Validate rollback artifacts are also map-free in release storage.
+
+## False Positives and Exceptions
+
+- Private internal tools served only behind corporate SSO and network controls
+- Short-lived troubleshooting releases with approved exception and explicit expiry
+- Source maps uploaded privately to monitoring vendor, not served publicly
+- Bundles where maps exist on disk but are never deployed to public hosts
+
+## Related Rules
+
+- `TG-CLIENT-002-sensitive-client-bundle-content.md`
+- `TG-PLATFORM-003-production-stack-trace-exposure.md`
+- `TG-SEC-002-public-environment-secrets.md`

package/.torusguard/rules/TG-CLIENT-002-sensitive-client-bundle-content.md

@@ -0,0 +1,102 @@
+# TG-CLIENT-002: Sensitive Client Bundle Content
+
+## Severity
+
+High
+
+## Applies To
+
+- Frontend JavaScript/TypeScript bundles shipped to browsers
+- React, Next.js, Vite, CRA, and other web client builds
+- Client logs (`console.log`, telemetry breadcrumbs, debug overlays)
+- Embedded config constants and generated runtime environment payloads
+- Source files that may be tree-shaken incorrectly but still leak literals
+
+## Why It Matters
+
+Anything shipped to the browser is attacker-accessible by design.
+Secrets, tokens, admin keys, or internal endpoints in bundles are effectively public.
+Sensitive debug logs can leak credentials into screenshots and support tickets.
+A single hardcoded secret can enable direct backend or third-party API compromise.
+This is a high-impact exposure class and often immediately exploitable.
+Browser DevTools cannot be blocked, so any client-shipped secret should be treated as compromised.
+
+## What TorusGuard Looks For
+
+- Hardcoded API keys, bearer tokens, private keys, or signing secrets in client code
+- Usage of server-only env vars in frontend modules
+- `console.log`/`console.debug` outputting JWTs, session tokens, or PII
+- Debug utilities that serialize auth headers or full user objects in production
+- References to admin-only endpoints from unauthenticated client paths
+- Bundle artifacts containing known secret patterns or credential-like strings
+
+## Unsafe Example
+
+```ts
+// src/api/client.ts
+const ADMIN_TOKEN = "sk_live_9f2a...supersecret";
+
+export async function createInvoice(payload: unknown) {
+  console.log("using token", ADMIN_TOKEN);
+  return fetch("https://api.example.com/admin/invoices", {
+    method: "POST",
+    headers: {
+      Authorization: `Bearer ${ADMIN_TOKEN}`,
+      "Content-Type": "application/json"
+    },
+    body: JSON.stringify(payload)
+  });
+}
+```
+
+## Safe Example
+
+```ts
+// src/api/client.ts
+export async function createInvoice(payload: unknown) {
+  return fetch("/api/invoices", {
+    method: "POST",
+    headers: { "Content-Type": "application/json" },
+    body: JSON.stringify(payload)
+  });
+}
+
+// server route uses server-side credentials only
+app.post("/api/invoices", requireAuth, async (req, res) => {
+  const result = await billing.createInvoice(req.user.id, req.body);
+  res.json(result);
+});
+```
+
+## Remediation
+
+1. Remove all secrets and privileged tokens from client code and build-time env payloads.
+2. Move privileged API calls behind server endpoints with proper authz checks.
+3. Restrict frontend env variables to explicitly public-safe values only.
+4. Strip sensitive console statements in production builds.
+5. Add CI secret scanning for source and compiled bundles.
+6. Rotate any leaked credentials immediately and revoke prior tokens.
+7. Add code review gates that block server-only value usage in client modules.
+8. Educate teams that browser code is always inspectable by users and attackers.
+
+## Verification
+
+- Inspect built bundles and search for token/key patterns and internal secrets.
+- Run app in production mode and confirm no sensitive console output.
+- Verify privileged operations require server-mediated authentication and authorization.
+- Validate rotated credentials are active and leaked values are revoked.
+- Confirm public env allowlist is enforced in CI/build scripts.
+
+## False Positives and Exceptions
+
+- Public publishable keys intentionally designed for client use (documented by vendor)
+- Fake/sample credentials used only in local demo code outside production builds
+- Debug logs in non-production branches that are stripped before release
+- Internal tools with private distribution, if risk accepted explicitly
+
+## Related Rules
+
+- `TG-SEC-001-hardcoded-secrets.md`
+- `TG-SEC-002-public-environment-secrets.md`
+- `TG-CLIENT-001-public-production-source-maps.md`
+- `TG-AUTH-002-client-only-authorization.md`

package/.torusguard/rules/TG-DB-001-frontend-database-query.md

@@ -0,0 +1,83 @@
+# TG-DB-001: Frontend Database Query Logic
+
+## Severity
+High
+
+## Applies To
+- Frontend source paths such as `src/`, `app/`, `pages/`, `components/`, `client/`, `public/`
+- Browser-executed JavaScript and TypeScript bundles
+- SSR-hybrid projects where code placement can blur server/client boundaries
+- Shared utility modules imported by frontend entry points
+
+## Why It Matters
+Executing SQL construction or raw database access logic in frontend code exposes internal schema assumptions and trust boundaries.  
+Even if direct DB connectivity fails in browsers, query logic can leak sensitive structure, encourage insecure architecture, and lead to credential exposure attempts.  
+Database interaction must stay on trusted server infrastructure with controlled authorization.
+
+## What TorusGuard Looks For
+- SQL strings (`SELECT`, `INSERT`, `UPDATE`, `DELETE`) in frontend-scoped files
+- Query builders or DB clients imported into client-rendered modules
+- Functions assembling SQL fragments from user input in browser code
+- Mentions of table names, admin joins, or migration SQL in UI components
+- Direct network calls from frontend intended for database endpoints
+
+## Unsafe Example
+```ts
+// src/components/UserLookup.tsx
+export function loadUserByEmail(email: string) {
+  const sql = `SELECT id, role FROM users WHERE email = '${email}' LIMIT 1`;
+
+  return fetch("/db/query", {
+    method: "POST",
+    headers: { "content-type": "application/json" },
+    body: JSON.stringify({ sql }),
+  }).then((r) => r.json());
+}
+```
+
+## Safe Example
+```ts
+// src/components/UserLookup.tsx
+export function loadUserByEmail(email: string) {
+  return fetch("/api/users/lookup", {
+    method: "POST",
+    headers: { "content-type": "application/json" },
+    body: JSON.stringify({ email }),
+  }).then((r) => r.json());
+}
+```
+
+```ts
+// server/routes/users.ts
+app.post("/api/users/lookup", async (req, res) => {
+  const user = await userRepo.findByEmail(req.body.email);
+  res.json({ id: user?.id, role: user?.role ?? "none" });
+});
+```
+
+## Remediation (numbered)
+1. Remove SQL strings and database query logic from frontend-scoped files.
+2. Move all data access into backend APIs, repositories, or service layers.
+3. Validate and authorize request parameters on the server before querying.
+4. Return minimal response shapes needed by the UI.
+5. Review frontend imports to prevent accidental DB client inclusion.
+6. Add static checks that disallow SQL keywords in client-targeted directories.
+7. Document architecture boundaries between browser code and data layers.
+
+## Verification
+- Scan frontend paths for SQL keywords and DB client imports.
+- Confirm browser bundles contain no query builders or SQL literals.
+- Validate data retrieval flows through authenticated backend endpoints.
+- Test unauthorized requests to ensure server-side access controls hold.
+- Review code ownership and lint rules enforcing client/server separation.
+
+## False Positives and Exceptions
+- Static tutorial snippets in markdown may contain SQL and are non-executable.
+- Demo strings in tests are acceptable if isolated from production bundles.
+- Client files that only reference SQL terms in copy text are low risk.
+- Exceptions should be time-bound and approved by architecture owners.
+
+## Related Rules
+- [TG-DB-002](./TG-DB-002-privileged-database-credential.md) - Privileged DB credentials in browser exposure
+- [TG-DB-003](./TG-DB-003-frontend-admin-sdk.md) - Admin/server SDK usage in frontend code
+- [TG-SEC-002](./TG-SEC-002-public-environment-secrets.md) - Public-prefixed secret leakage

package/.torusguard/rules/TG-DB-002-privileged-database-credential.md

@@ -0,0 +1,86 @@
+# TG-DB-002: Privileged Database Credential in Browser Context
+
+## Severity
+Critical
+
+## Applies To
+- Browser-executed code in frontend apps and static assets
+- Public environment variables consumed by client bundles
+- Mobile web, desktop web, and embedded webview clients
+- Shared modules imported into client-side runtime
+
+## Why It Matters
+Privileged database credentials in browser-accessible code grant attackers direct or indirect control over sensitive data stores.  
+Service-role keys and admin database URLs typically bypass row-level access controls and can expose full datasets.  
+Because frontend artifacts are publicly retrievable, embedded privileged credentials should be treated as compromised.
+
+## What TorusGuard Looks For
+- Service-role keys and admin tokens referenced in frontend code
+- Database URLs containing usernames/passwords in browser-executed modules
+- Public env variables with names such as:
+  - `NEXT_PUBLIC_DATABASE_URL`
+  - `VITE_SUPABASE_SERVICE_ROLE_KEY`
+  - `REACT_APP_ADMIN_DB_TOKEN`
+- Client initialization using elevated credentials intended for server trust zones
+- Fallback credential constants used when env vars are missing
+
+## Unsafe Example
+```ts
+// src/lib/dbClient.ts
+import { createClient } from "@supabase/supabase-js";
+
+const url = process.env.NEXT_PUBLIC_DATABASE_URL!;
+const serviceRole = process.env.NEXT_PUBLIC_SUPABASE_SERVICE_ROLE_KEY!;
+
+export const db = createClient(url, serviceRole, {
+  auth: { persistSession: false },
+});
+```
+
+## Safe Example
+```ts
+// src/lib/publicClient.ts
+import { createClient } from "@supabase/supabase-js";
+
+const url = process.env.NEXT_PUBLIC_SUPABASE_URL!;
+const anonKey = process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!;
+
+export const publicDb = createClient(url, anonKey);
+```
+
+```ts
+// server/lib/adminDb.ts
+import { createClient } from "@supabase/supabase-js";
+
+export const adminDb = createClient(
+  process.env.SUPABASE_URL!,
+  process.env.SUPABASE_SERVICE_ROLE_KEY!,
+);
+```
+
+## Remediation (numbered)
+1. Remove privileged DB credentials from all frontend and public env sources.
+2. Rotate exposed service-role keys, passwords, and privileged tokens immediately.
+3. Migrate privileged operations to backend-only services and APIs.
+4. Use least-privilege client credentials (anonymous/public keys) in browser code.
+5. Audit access logs for misuse during exposure window.
+6. Enforce CI policy blocking privileged credential names in public scopes.
+7. Add architecture documentation defining credential trust boundaries.
+
+## Verification
+- Inspect client bundles and source maps for privileged credential artifacts.
+- Confirm frontend uses only non-privileged credentials and constrained APIs.
+- Validate server-only secrets are loaded from private runtime environments.
+- Test rotated privileged credentials and verify old keys are rejected.
+- Review monitoring for anomalous database access during and after remediation.
+
+## False Positives and Exceptions
+- Public anonymous keys may look secret-like but are intentionally non-privileged.
+- Documentation examples can trigger detections; verify they are non-operational.
+- Local-only sandbox credentials are still risky if bundled into distributed builds.
+- Exceptions require security approval, owner assignment, and expiration date.
+
+## Related Rules
+- [TG-SEC-001](./TG-SEC-001-hardcoded-secrets.md) - Hardcoded secrets in tracked source
+- [TG-SEC-002](./TG-SEC-002-public-environment-secrets.md) - Secrets in public env namespaces
+- [TG-DB-003](./TG-DB-003-frontend-admin-sdk.md) - Admin SDK usage in frontend runtime

package/.torusguard/rules/TG-DB-003-frontend-admin-sdk.md

@@ -0,0 +1,91 @@
+# TG-DB-003: Frontend Use of Admin or Server-Only Database SDKs
+
+## Severity
+Critical
+
+## Applies To
+- Frontend directories such as `src/`, `app/`, `pages/`, `components/`, `client/`, `public/`
+- Browser bundles in React, Next.js client components, Vite, and CRA
+- Shared package imports consumed by client entry points
+- Build systems that can accidentally include server-only dependencies
+
+## Why It Matters
+Admin SDKs and server drivers are designed for trusted environments and often assume unrestricted credentials and network access.  
+Using packages like Firebase Admin, Prisma, or `pg` in frontend paths risks exposing privileged behavior, credentials, and internal data models.  
+Even failed browser execution can leak sensitive implementation details and weaken architectural boundaries.
+
+## What TorusGuard Looks For
+- Imports of server-only SDKs in frontend-targeted files:
+  - `firebase-admin`
+  - `@prisma/client`
+  - `pg`
+- Initialization logic for admin clients in UI components or client utilities
+- Conditional imports attempting to bypass bundler checks in browser code
+- Code patterns that create server DB connections in frontend modules
+- Shared files that instantiate privileged clients and are imported by frontend
+
+## Unsafe Example
+```ts
+// src/app/dashboard/adminMetrics.tsx
+import { PrismaClient } from "@prisma/client";
+import { Client } from "pg";
+
+const prisma = new PrismaClient();
+const pgClient = new Client({
+  connectionString: process.env.NEXT_PUBLIC_DATABASE_URL,
+});
+
+export async function loadMetrics() {
+  await pgClient.connect();
+  const result = await prisma.user.count();
+  return { users: result };
+}
+```
+
+## Safe Example
+```ts
+// src/app/dashboard/adminMetrics.tsx
+export async function loadMetrics() {
+  const res = await fetch("/api/admin/metrics", { method: "GET" });
+  return res.json();
+}
+```
+
+```ts
+// server/routes/adminMetrics.ts
+import { PrismaClient } from "@prisma/client";
+
+const prisma = new PrismaClient();
+
+app.get("/api/admin/metrics", async (_req, res) => {
+  const users = await prisma.user.count();
+  res.json({ users });
+});
+```
+
+## Remediation (numbered)
+1. Remove server-only SDK imports from frontend and browser-targeted modules.
+2. Relocate privileged data access to backend routes, jobs, or server actions.
+3. Ensure frontend calls authenticated backend endpoints for required data.
+4. Restrict server-only dependencies to backend package boundaries.
+5. Configure bundler/lint rules to block admin SDK imports in frontend paths.
+6. Rotate credentials if admin SDK usage exposed privileged config values.
+7. Add architecture tests validating strict client/server dependency separation.
+
+## Verification
+- Scan frontend directories for imports of `firebase-admin`, Prisma, and `pg`.
+- Confirm build output excludes server-only database packages in client chunks.
+- Validate admin operations execute only on server infrastructure.
+- Run access-control tests against backend endpoints exposing admin data.
+- Review dependency graphs to ensure no frontend transitive path to admin SDKs.
+
+## False Positives and Exceptions
+- Type-only imports can appear suspicious; verify they are erased at build time.
+- Documentation snippets in markdown are non-runtime and may be acceptable.
+- Server components must be verified carefully to avoid accidental client inclusion.
+- Exceptions require documented risk acceptance and periodic security review.
+
+## Related Rules
+- [TG-DB-001](./TG-DB-001-frontend-database-query.md) - Frontend SQL/query logic anti-pattern
+- [TG-DB-002](./TG-DB-002-privileged-database-credential.md) - Privileged credential exposure in browser
+- [TG-SEC-001](./TG-SEC-001-hardcoded-secrets.md) - Hardcoded sensitive literals in source

package/.torusguard/rules/TG-DB-004-missing-tenant-query-isolation.md

@@ -0,0 +1,103 @@
+---
+id: TG-DB-004
+title: Missing Tenant Query Isolation in Multi-Tenant Models
+category: data-access-orm
+severity: Critical
+confidence: Confirmed
+frameworks:
+  - django
+  - drf
+  - fastapi
+  - flask
+  - sqlalchemy
+cwe: CWE-284
+asvs_v4: V4.1.3
+nist_ssdf: PW.5.1
+---
+
+# TG-DB-004: Missing Tenant Query Isolation in Multi-Tenant Models
+
+## 🚨 Problem Statement
+Applications built on a multi-tenant architecture often fail to scope database lookups (`SELECT`, `UPDATE`, `DELETE`) by the current authenticated tenant. Allowing a direct primary key (ID) lookup without a composite tenant filter allows Insecure Direct Object Reference (IDOR) attacks, enabling users to access or modify data belonging to other tenants.
+
+> **Tuning Guardrails (v0.5.6):**
+> - **DO NOT flag** every primary-key lookup.
+> - **ESCALATE** when tenant-owned data can be loaded or modified without a verified tenant scope.
+> - **DETECT** established tenant-scoped managers, repositories, `get_queryset()`, dependency injection, or parent-resource ownership checks.
+> - **MARK** complex multi-layer scope flows as `Needs Review` instead of `Confirmed` when source-only proof is inadequate.
+
+---
+
+## 💥 Adversarial Threat & Exploitation
+An attacker from Tenant B supplies the record UUID of a confidential document belonging to Tenant A:
+```http
+GET /api/v1/invoices/9b1deb4d-3b7d-4bad-9bdd-2b0d7b3dcb6d HTTP/1.1
+Host: saas.example.com
+Authorization: Bearer <Tenant_B_JWT>
+```
+If the backend performs `session.get(Invoice, invoice_id)` or `Invoice.objects.get(id=invoice_id)` without scoping to `tenant_id=current_user.tenant_id`, the invoice belonging to Tenant A is returned to the attacker.
+
+---
+
+## 🛠️ Framework-Native Remediations
+
+### 🐍 SQLAlchemy (Scoped Tenant Queries)
+
+#### ❌ Unsafe Pattern
+```python
+# Unsafe: Global primary key lookup without tenant filter
+@app.get("/invoices/{invoice_id}")
+def get_invoice(invoice_id: str, db: Session = Depends(get_db), user: User = Depends(get_current_user)):
+    invoice = db.query(Invoice).filter(Invoice.id == invoice_id).first()
+    if not invoice:
+        raise HTTPException(status_code=404, detail="Invoice not found")
+    return invoice
+```
+
+#### ✅ Safe Remediation
+```python
+# Safe: Enforce tenant scoping on every query filter
+@app.get("/invoices/{invoice_id}")
+def get_invoice(invoice_id: str, db: Session = Depends(get_db), user: User = Depends(get_current_user)):
+    invoice = (
+        db.query(Invoice)
+        .filter(Invoice.id == invoice_id, Invoice.tenant_id == user.tenant_id)
+        .first()
+    )
+    if not invoice:
+        raise HTTPException(status_code=404, detail="Invoice not found")
+    return invoice
+```
+
+---
+
+### 🐍 Django ORM (Scoped Manager / ViewSet Queryset)
+
+#### ❌ Unsafe Pattern
+```python
+# Unsafe: Global queryset in DRF ViewSet
+class InvoiceViewSet(viewsets.ModelViewSet):
+    queryset = Invoice.objects.all()  # Exposes all tenant records
+    serializer_class = InvoiceSerializer
+```
+
+#### ✅ Safe Remediation
+```python
+# Safe: Override get_queryset to enforce tenant boundary on every request
+class InvoiceViewSet(viewsets.ModelViewSet):
+    serializer_class = InvoiceSerializer
+    permission_classes = [permissions.IsAuthenticated]
+
+    def get_queryset(self):
+        # Strictly scope lookups to authenticated user's organization
+        return Invoice.objects.filter(tenant=self.request.user.tenant)
+```
+
+---
+
+## 🧪 Verification & Reproduction
+1. Send request with valid Tenant B token requesting Tenant A resource ID:
+   ```bash
+   curl -H "Authorization: Bearer <Tenant_B_Token>" http://localhost:8000/invoices/<Tenant_A_UUID>
+   ```
+2. **Assertion:** Request must return `404 Not Found`, denying access to cross-tenant data.

package/.torusguard/rules/TG-INPUT-001-missing-server-validation.md

@@ -0,0 +1,98 @@
+# TG-INPUT-001: Missing Server-Side Validation
+
+## Severity
+High
+
+## Applies To
+- REST and GraphQL API handlers
+- Form-processing backend endpoints
+- Message queue consumers that accept external payloads
+- Admin/import endpoints that trust UI validation
+
+## Why It Matters
+Client-side checks are easy to bypass because attackers can send crafted requests directly to backend endpoints.
+When the server does not validate required fields, data type, length, format, range, and allowed values, malicious input can trigger account takeover paths, integrity failures, and downstream injection vulnerabilities.
+Server-side validation is also required to keep business rules enforceable when multiple clients, scripts, and integrations call the same APIs.
+
+## What TorusGuard Looks For
+- Request data read from `req.body`, `req.query`, `req.params`, headers, or raw payloads without schema validation.
+- Validation done only in frontend files while backend endpoint accepts the same fields blindly.
+- Direct persistence of user-provided objects with broad spread operators.
+- Type coercion and fallback logic that silently accepts invalid values.
+- Missing allowlists for enum-like fields such as role, status, country code, or operation type.
+
+## Unsafe Example
+```js
+// Express route that trusts client validation
+app.post("/api/profile", async (req, res) => {
+  const { displayName, age, newsletter, role } = req.body;
+
+  // No server-side validation:
+  // - displayName could be extremely long or contain control chars
+  // - age could be negative or non-numeric
+  // - newsletter could be arbitrary string
+  // - role could be escalated to "admin"
+  const updated = await db.user.update({
+    where: { id: req.user.id },
+    data: { displayName, age, newsletter, role }
+  });
+
+  res.json({ ok: true, user: updated });
+});
+```
+
+## Safe Example
+```js
+import { z } from "zod";
+
+const updateProfileSchema = z.object({
+  displayName: z.string().min(2).max(60).regex(/^[a-zA-Z0-9 _.-]+$/),
+  age: z.number().int().min(13).max(120),
+  newsletter: z.boolean(),
+  role: z.enum(["user"]) // client cannot self-assign privileged roles
+});
+
+app.post("/api/profile", async (req, res) => {
+  const parsed = updateProfileSchema.safeParse(req.body);
+  if (!parsed.success) {
+    return res.status(400).json({
+      ok: false,
+      error: "Invalid input",
+      details: parsed.error.issues
+    });
+  }
+
+  const { displayName, age, newsletter } = parsed.data;
+  const updated = await db.user.update({
+    where: { id: req.user.id },
+    data: { displayName, age, newsletter }
+  });
+
+  res.json({ ok: true, user: updated });
+});
+```
+
+## Remediation
+1. Define strict server-side schemas for every externally reachable input surface.
+2. Validate before business logic, authorization decisions, and database writes.
+3. Enforce field allowlists; reject unexpected keys rather than silently ignoring them.
+4. Apply normalization after validation (trim, case-fold, canonical forms) where needed.
+5. Centralize reusable validators for shared payloads to prevent drift across endpoints.
+6. Return clear but non-sensitive validation errors, and log rejection metrics for monitoring.
+
+## Verification
+- Send malformed payloads directly with `curl` or API clients, bypassing the web UI.
+- Confirm invalid types, out-of-range values, and unknown fields return `400`.
+- Attempt privilege-related field tampering and verify values are rejected or ignored safely.
+- Run integration tests covering boundary values and negative cases.
+- Ensure validation runs for all entry paths, including batch/import and background worker routes.
+
+## False Positives and Exceptions
+- Internal service-to-service endpoints may appear unvalidated but can be acceptable if strong contract validation is enforced at the gateway and mutual trust boundaries are documented.
+- Auto-generated API frameworks sometimes perform implicit validation; keep explicit schema definitions for auditability.
+- Legacy endpoints under migration can be temporarily exempted only with compensating controls and a tracked deprecation timeline.
+
+## Related Rules
+- [TG-INPUT-002](./TG-INPUT-002-raw-sql-concatenation.md)
+- [TG-INPUT-003](./TG-INPUT-003-unsafe-html-or-code-execution.md)
+- [TG-AUTH-003](./TG-AUTH-003-missing-object-authorization.md)