torusguard 1.3.0 → 1.3.2

package/skills/torusguard/payload/rules/active/TG-RATE-001-unlimited-auth-endpoint.md

@@ -0,0 +1,112 @@
+# TG-RATE-001: Unlimited Authentication Endpoint
+
+## Severity
+
+High
+
+## Applies To
+
+- Login endpoints (`/login`, `/signin`, `/api/auth/login`)
+- Password reset request endpoints
+- OTP and magic-link request endpoints
+- Token exchange and refresh endpoints exposed to internet clients
+
+## Why It Matters
+
+Authentication surfaces are high-value brute-force targets.
+Without request throttling, attackers can attempt large credential lists quickly.
+Even with strong password hashing, unlimited retries can cause account takeover.
+Unauthenticated auth endpoints are also cheap to hit from botnets.
+Excessive failures can degrade performance and create noisy logs.
+Credential stuffing campaigns usually start here before lateral abuse.
+
+## What TorusGuard Looks For
+
+- Auth route handlers with no middleware or logic that tracks attempts
+- No dependency usage for rate limiting (`express-rate-limit`, Redis counters, gateway policies)
+- Missing per-identity or per-IP backoff decisions on failed auth
+- Password reset or OTP endpoints callable repeatedly without cooldown
+- Comments or TODOs that acknowledge rate limiting is not implemented
+- Reverse proxy configs that do not define request limits for auth paths
+
+## Unsafe Example
+
+```ts
+import express from "express";
+import { verifyPassword } from "./auth";
+
+const app = express();
+app.use(express.json());
+
+app.post("/api/auth/login", async (req, res) => {
+  const { email, password } = req.body;
+  const user = await db.user.findUnique({ where: { email } });
+
+  if (!user || !(await verifyPassword(password, user.passwordHash))) {
+    return res.status(401).json({ error: "Invalid credentials" });
+  }
+
+  return res.json({ token: signJwt({ sub: user.id }) });
+});
+```
+
+## Safe Example
+
+```ts
+import express from "express";
+import rateLimit from "express-rate-limit";
+import { verifyPassword } from "./auth";
+
+const app = express();
+app.use(express.json());
+
+const authLimiter = rateLimit({
+  windowMs: 15 * 60 * 1000,
+  max: 10,
+  standardHeaders: true,
+  legacyHeaders: false,
+  message: { error: "Too many authentication attempts. Try later." }
+});
+
+app.post("/api/auth/login", authLimiter, async (req, res) => {
+  const { email, password } = req.body;
+  const user = await db.user.findUnique({ where: { email } });
+  if (!user || !(await verifyPassword(password, user.passwordHash))) {
+    return res.status(401).json({ error: "Invalid credentials" });
+  }
+  return res.json({ token: signJwt({ sub: user.id }) });
+});
+```
+
+## Remediation
+
+1. Identify every internet-facing authentication and account-recovery endpoint.
+2. Apply a rate limiter at app, gateway, or CDN edge for those routes.
+3. Add tighter thresholds for auth than for generic API traffic.
+4. Layer controls: per-IP + per-account/email counters when possible.
+5. Introduce cooldown/backoff after repeated failures.
+6. Return uniform auth errors to avoid account enumeration.
+7. Ensure limits are distributed (Redis or gateway), not in-process only.
+8. Alert on sustained throttling spikes as potential credential-stuffing.
+
+## Verification
+
+- Trigger more than allowed login failures from a single source and confirm `429`.
+- Confirm `Retry-After` or equivalent response hints are present.
+- Validate successful logins still work under normal user behavior.
+- Verify limits apply to reset, OTP, and magic-link request endpoints too.
+- Inspect deployment gateway/WAF config to ensure parity with app behavior.
+
+## False Positives and Exceptions
+
+- Internal service-to-service auth endpoints behind private network controls only
+- Endpoints already protected by managed API gateway quotas with strict scopes
+- Staging environments used only in private CI where public traffic is impossible
+- Temporary elevated limits during controlled load tests (must be time-boxed)
+
+## Related Rules
+
+- `TG-AUTH-005-unsafe-password-reset.md`
+- `TG-AUTH-001-weak-password-storage.md`
+- `TG-RATE-002-unlimited-public-write-endpoint.md`
+- `TG-RATE-003-unbounded-resource-consumption.md`

package/skills/torusguard/payload/rules/active/TG-RATE-002-unlimited-public-write-endpoint.md

@@ -0,0 +1,109 @@
+# TG-RATE-002: Unlimited Public Write Endpoint
+
+## Severity
+
+Medium
+
+## Applies To
+
+- Contact forms and feedback submission routes
+- Newsletter signup and waitlist endpoints
+- Anonymous content creation or comment endpoints
+- Webhooks that accept unauthenticated internet traffic
+- Any expensive POST/PUT/PATCH endpoint callable pre-auth
+
+## Why It Matters
+
+Public write endpoints are common abuse entry points.
+Attackers can flood storage, queues, email providers, and notification systems.
+Abuse may not be data theft, but can still create real cost and downtime.
+Spam and bot traffic can also degrade analytics and operational trust.
+Unchecked write volume becomes an easy denial-of-wallet vector.
+
+## What TorusGuard Looks For
+
+- Unauthenticated write handlers without route-level throttling
+- Missing CAPTCHA or bot challenge on high-abuse forms
+- No IP, device, or fingerprint-based submission controls
+- No duplicate submission detection for identical payloads
+- Lack of queue depth or outbound provider safeguards after intake
+- Public webhooks with no signature check plus no request limits
+
+## Unsafe Example
+
+```ts
+app.post("/api/contact", async (req, res) => {
+  await db.contactMessage.create({
+    data: {
+      email: req.body.email,
+      message: req.body.message
+    }
+  });
+
+  await mailer.send({
+    to: "support@example.com",
+    subject: "New contact request",
+    text: req.body.message
+  });
+
+  res.status(201).json({ ok: true });
+});
+```
+
+## Safe Example
+
+```ts
+import rateLimit from "express-rate-limit";
+
+const publicWriteLimiter = rateLimit({
+  windowMs: 10 * 60 * 1000,
+  max: 20,
+  message: { error: "Too many submissions. Please retry later." },
+  standardHeaders: true,
+  legacyHeaders: false
+});
+
+app.post("/api/contact", publicWriteLimiter, async (req, res) => {
+  if (!req.body.captchaToken || !(await captcha.verify(req.body.captchaToken))) {
+    return res.status(400).json({ error: "Bot challenge failed" });
+  }
+
+  await db.contactMessage.create({
+    data: { email: req.body.email, message: req.body.message }
+  });
+  res.status(201).json({ ok: true });
+});
+```
+
+## Remediation
+
+1. Inventory all anonymous or pre-auth write endpoints.
+2. Add route-specific rate limits with lower thresholds than authenticated APIs.
+3. Add anti-automation controls (CAPTCHA, proof-of-work, or managed bot defense).
+4. Deduplicate repeated payloads to reduce spam amplification.
+5. Gate downstream expensive actions (email, SMS, AI calls) with quotas.
+6. Enforce signed webhooks where feasible and rate-limit unsigned traffic heavily.
+7. Add abuse monitoring dashboards for submission spikes and block decisions.
+8. Define an incident playbook for emergency tightening of public write limits.
+
+## Verification
+
+- Send more than allowed form submissions and confirm throttling responses.
+- Confirm bot challenge is required and invalid tokens are rejected.
+- Verify normal user submission paths remain functional.
+- Test downstream providers are not called when requests are throttled.
+- Review logs to ensure abuse signals are observable and actionable.
+
+## False Positives and Exceptions
+
+- Endpoint is private behind VPN and not internet-reachable
+- Strict gateway quota exists with documented ownership and alerts
+- Endpoint is read-mostly and mislabeled as write by route naming only
+- Temporary load-test bypass with approved window and post-test rollback
+
+## Related Rules
+
+- `TG-RATE-001-unlimited-auth-endpoint.md`
+- `TG-RATE-003-unbounded-resource-consumption.md`
+- `TG-INPUT-001-missing-server-validation.md`
+- `TG-INPUT-004-unrestricted-file-upload.md`

package/skills/torusguard/payload/rules/active/TG-RATE-003-unbounded-resource-consumption.md

@@ -0,0 +1,105 @@
+# TG-RATE-003: Unbounded Resource Consumption
+
+## Severity
+
+High
+
+## Applies To
+
+- Search and reporting endpoints with user-controlled pagination or filters
+- File generation/export endpoints (CSV, PDF, ZIP)
+- Media processing, image transforms, and AI inference routes
+- Query parameters controlling recursion depth, fan-out, or batch size
+- Any endpoint that triggers heavy DB, CPU, memory, or outbound calls
+
+## Why It Matters
+
+Not all abuse is about raw request count.
+A single request can be dangerously expensive when workload is unbounded.
+Attackers can force large scans, huge responses, or runaway processing jobs.
+This can produce denial-of-service and significant infrastructure cost.
+Legitimate users also suffer from latency and instability during abuse events.
+
+## What TorusGuard Looks For
+
+- Missing upper bounds on `limit`, `pageSize`, `depth`, `expand`, or `batchSize`
+- Export endpoints that allow entire dataset extraction in one request
+- Image/AI endpoints with unrestricted dimensions, duration, or token budgets
+- No request timeouts, execution budgets, or cancellation support
+- DB queries lacking pagination while returning client-controlled result sizes
+- Loops over user-provided ranges without hard caps
+
+## Unsafe Example
+
+```ts
+app.get("/api/reports/users", async (req, res) => {
+  const limit = Number(req.query.limit ?? 1000);
+  const users = await db.user.findMany({
+    where: { active: true },
+    take: limit
+  });
+  res.json({ users });
+});
+
+app.post("/api/export", async (req, res) => {
+  const rows = await db.orders.findMany(); // full table scan/export
+  const csv = await toCsv(rows);
+  res.type("text/csv").send(csv);
+});
+```
+
+## Safe Example
+
+```ts
+const MAX_REPORT_LIMIT = 100;
+const MAX_EXPORT_ROWS = 5000;
+
+app.get("/api/reports/users", async (req, res) => {
+  const requested = Number(req.query.limit ?? 25);
+  const limit = Math.min(Math.max(requested, 1), MAX_REPORT_LIMIT);
+  const users = await db.user.findMany({
+    where: { active: true },
+    take: limit
+  });
+  res.json({ users, limit });
+});
+
+app.post("/api/export", async (req, res) => {
+  const rows = await db.orders.findMany({ take: MAX_EXPORT_ROWS });
+  const csv = await toCsv(rows);
+  res.type("text/csv").send(csv);
+});
+```
+
+## Remediation
+
+1. Define explicit upper bounds for all user-controlled workload parameters.
+2. Clamp values server-side even when frontend already validates inputs.
+3. Require pagination for list endpoints and deny unbounded bulk reads.
+4. Add compute and execution guardrails (timeouts, cancellation, queue budgets).
+5. Cap export size and move large jobs to async pipelines with quotas.
+6. Set sane payload and response size thresholds per route type.
+7. Add observability for p95/p99 cost, timeout, and reject rates by endpoint.
+8. Load-test abuse scenarios and tune bounds before production rollout.
+
+## Verification
+
+- Request extreme `limit`/`depth` values and verify clamping behavior.
+- Confirm oversized exports are blocked or converted to queued async jobs.
+- Measure endpoint latency under stress and verify no runaway degradation.
+- Validate timeout and cancellation behavior for long-running workloads.
+- Ensure alerting fires when expensive request patterns spike.
+
+## False Positives and Exceptions
+
+- Internal analytics jobs running on private networks with dedicated quotas
+- One-off administrative endpoints gated by strong auth and network controls
+- Batch endpoints with strict signed-client access and audited operator use
+- Synthetic benchmarks intentionally disabling caps in isolated environments
+
+## Related Rules
+
+- `TG-RATE-001-unlimited-auth-endpoint.md`
+- `TG-RATE-002-unlimited-public-write-endpoint.md`
+- `TG-PLATFORM-004-missing-request-size-limits.md`
+- `TG-INPUT-001-missing-server-validation.md`

package/skills/torusguard/payload/rules/active/TG-SEC-001-hardcoded-secrets.md

@@ -0,0 +1,83 @@
+# TG-SEC-001: Hardcoded Secrets in Tracked Source
+
+## Severity
+Critical
+
+## Applies To
+- JavaScript, TypeScript, Python, Go, Java, C#, Ruby, PHP
+- Backend services, scripts, CI helpers, and shared utilities
+- Any tracked file in `src/`, `app/`, `server/`, `api/`, `scripts/`, or `lib/`
+- Infrastructure manifests that can hold credentials
+
+## Why It Matters
+Hardcoded secrets in source control are frequently harvested by automated scanners within minutes of exposure.  
+Once committed, credentials may remain accessible through forks, clones, build logs, and historical refs even after removal.  
+Leaked API keys, JWT secrets, passwords, and database URLs can enable privilege escalation, data exfiltration, and account takeover.
+
+## What TorusGuard Looks For
+- String literals assigned to names such as `apiKey`, `token`, `jwtSecret`, `password`, `dbUrl`, `connectionString`
+- Credential-shaped values in code, including:
+  - Long base64-like tokens
+  - Hex secrets
+  - URLs with embedded credentials (`protocol://user:pass@host`)
+- Insecure defaults like `JWT_SECRET = "change-me"` left in tracked files
+- Commented-out credentials that still exist in committed code
+- Secret values in configuration source files (`.ts`, `.js`, `.py`, `.yaml`, `.json`)
+
+## Unsafe Example
+```ts
+// src/auth/session.ts
+import jwt from "jsonwebtoken";
+
+const JWT_SECRET = "prod_jwt_secret_8392b76ed18bb1";
+const adminPassword = "S3rv!ce-Adm1n-Temp";
+const dbUrl = "postgres://app_user:PlainTextPass@db.internal:5432/payments";
+
+export function signSession(payload: object) {
+  return jwt.sign(payload, JWT_SECRET, { expiresIn: "1h" });
+}
+```
+
+## Safe Example
+```ts
+// src/auth/session.ts
+import jwt from "jsonwebtoken";
+
+const JWT_SECRET = process.env.JWT_SECRET;
+const DB_URL = process.env.DATABASE_URL;
+
+if (!JWT_SECRET) {
+  throw new Error("Missing JWT_SECRET environment variable");
+}
+
+export function signSession(payload: object) {
+  return jwt.sign(payload, JWT_SECRET, { expiresIn: "1h" });
+}
+```
+
+## Remediation (numbered)
+1. Remove hardcoded credentials from tracked source files immediately.
+2. Move all secrets to environment variables or a managed secrets provider.
+3. Rotate every exposed key, password, token, and signing secret.
+4. Invalidate active sessions or tokens derived from leaked secrets.
+5. Rewrite affected git history if required by policy and incident scope.
+6. Add pre-commit and CI secret scanning to prevent recurrence.
+7. Document the incident, impact, and completed rotations for auditability.
+
+## Verification
+- Search the repository for secret-like assignments and literal credentials.
+- Confirm runtime configuration loads from environment or secret manager.
+- Validate rotated credentials by checking old values no longer authenticate.
+- Review CI and deployment settings to ensure secret injection is externalized.
+- Ensure no credential-shaped literals remain in tracked source paths.
+
+## False Positives and Exceptions
+- Example/test fixtures are acceptable only when values are obviously fake.
+- Non-sensitive identifiers (public analytics IDs, harmless tenant IDs) may match patterns.
+- Internal placeholder strings are allowed if they are non-functional and non-deployable.
+- Exception approvals should be documented with justification and owner.
+
+## Related Rules
+- [TG-SEC-002](./TG-SEC-002-public-environment-secrets.md) - Public environment variable secret exposure
+- [TG-SEC-003](./TG-SEC-003-tracked-env-file.md) - Tracked environment file leakage
+- [TG-DB-002](./TG-DB-002-privileged-database-credential.md) - Privileged database credentials in browser code

package/skills/torusguard/payload/rules/active/TG-SEC-002-public-environment-secrets.md

@@ -0,0 +1,83 @@
+# TG-SEC-002: Secrets in Public Environment Variables
+
+## Severity
+Critical
+
+## Applies To
+- Frontend frameworks exposing build-time env vars to browser bundles
+- Vite (`VITE_*`), Next.js (`NEXT_PUBLIC_*`), CRA (`REACT_APP_*`)
+- Client-rendered pages, static exports, and edge-delivered frontend assets
+- Monorepos where frontend apps consume shared environment files
+
+## Why It Matters
+Public-prefixed environment variables are intentionally embedded into shipped JavaScript and are readable by any user.  
+Placing API secrets, private signing keys, or privileged service credentials in these variables effectively publishes them.  
+Exposure allows unauthorized API usage, quota theft, account compromise, and backend pivoting.
+
+## What TorusGuard Looks For
+- Secret-like values assigned to `VITE_*`, `NEXT_PUBLIC_*`, or `REACT_APP_*`
+- Names suggesting private intent despite public prefix:
+  - `VITE_JWT_SECRET`
+  - `NEXT_PUBLIC_DB_PASSWORD`
+  - `REACT_APP_SERVICE_ROLE_KEY`
+- Long tokens, private keys, and credential URLs in frontend env config
+- Client code directly reading sensitive public variables for auth or data access
+- Build scripts promoting server-only variables into public namespaces
+
+## Unsafe Example
+```env
+# .env.production
+NEXT_PUBLIC_STRIPE_SECRET_KEY=sk_live_51N9x...
+VITE_DB_URL=postgres://admin:supersecret@db.prod:5432/core
+REACT_APP_JWT_SIGNING_KEY=prod_signing_key_q2f8j1
+```
+
+```ts
+// src/lib/payments.ts
+export const stripeSecret = process.env.NEXT_PUBLIC_STRIPE_SECRET_KEY!;
+```
+
+## Safe Example
+```env
+# .env.production
+NEXT_PUBLIC_STRIPE_PUBLISHABLE_KEY=pk_live_51N9x...
+```
+
+```ts
+// src/lib/payments.ts
+export async function createCheckoutSession(cartId: string) {
+  const res = await fetch("/api/checkout/session", {
+    method: "POST",
+    headers: { "content-type": "application/json" },
+    body: JSON.stringify({ cartId }),
+  });
+  return res.json();
+}
+```
+
+## Remediation (numbered)
+1. Remove secrets from every `VITE_*`, `NEXT_PUBLIC_*`, and `REACT_APP_*` variable.
+2. Move sensitive values to server-only environment variables without public prefixes.
+3. Route privileged operations through backend APIs with access control.
+4. Rotate all credentials that were exposed in public frontend environments.
+5. Rebuild and redeploy frontend assets after variable cleanup.
+6. Add CI policy checks blocking secret-like values in public env namespaces.
+7. Update team docs to separate publishable keys from secret keys explicitly.
+
+## Verification
+- Inspect built bundles to ensure no secret values are embedded.
+- Validate frontend only references publishable or non-sensitive config.
+- Confirm backend endpoints own all privileged API calls.
+- Check environment templates for corrected naming and scope boundaries.
+- Ensure old exposed keys fail when tested after rotation.
+
+## False Positives and Exceptions
+- Publishable keys (for example, Stripe publishable key) are acceptable by design.
+- Public feature flags and app metadata can safely use public prefixes.
+- A value that looks random is not always secret; validate provider classification.
+- Exceptions require documented approval and periodic re-review.
+
+## Related Rules
+- [TG-SEC-001](./TG-SEC-001-hardcoded-secrets.md) - Hardcoded credential literals in source code
+- [TG-DB-002](./TG-DB-002-privileged-database-credential.md) - Privileged DB credentials exposed in browser code
+- [TG-DB-003](./TG-DB-003-frontend-admin-sdk.md) - Frontend use of admin/server-only SDKs

package/skills/torusguard/payload/rules/active/TG-SEC-003-tracked-env-file.md

@@ -0,0 +1,79 @@
+# TG-SEC-003: Tracked Environment File
+
+## Severity
+High
+
+## Applies To
+- Git repositories containing `.env`, `.env.local`, `.env.production`, or similar files
+- Application backends, frontend builds, deployment scripts, and tooling
+- Monorepos with per-package environment files
+- Any tracked path where secrets can be stored in plain text
+
+## Why It Matters
+Environment files are commonly used to store credentials, tokens, and connection strings.  
+When tracked by git, these values propagate to every clone, fork, mirror, and CI artifact.  
+Even if a file is later deleted, prior commits may retain sensitive data unless history is remediated.
+
+## What TorusGuard Looks For
+- `.env*` files present in tracked source control history or current index
+- Environment files committed outside approved template patterns
+- Presence of sensitive key names in tracked env files:
+  - `*_SECRET`, `*_TOKEN`, `*_PASSWORD`, `DATABASE_URL`, `SERVICE_ROLE_KEY`
+- Mismatch between `.gitignore` policy and tracked env artifacts
+- Commits that introduce plaintext operational credentials
+
+## Unsafe Example
+```bash
+# git status --short
+A  .env
+M  src/config.ts
+```
+
+```env
+# .env
+DATABASE_URL=postgres://report_user:R3portProdPass@db:5432/reports
+JWT_SECRET=invoice_signing_secret_2026
+REDIS_PASSWORD=cache_password_11
+```
+
+## Safe Example
+```gitignore
+# .gitignore
+.env
+.env.*
+!.env.example
+```
+
+```env
+# .env.example
+DATABASE_URL=
+JWT_SECRET=
+REDIS_PASSWORD=
+```
+
+## Remediation (numbered)
+1. Remove tracked `.env*` files from git index while preserving local copies.
+2. Add strict ignore rules for environment files in repository root and subprojects.
+3. Replace committed env files with sanitized `.env.example` templates.
+4. Rotate all credentials that existed in tracked environment files.
+5. Audit commit history to determine exposure scope and retention obligations.
+6. If required, perform approved history rewrite and coordinate downstream cleanup.
+7. Enforce pre-commit and CI checks that block tracked secret-bearing env files.
+
+## Verification
+- Run git status and confirm `.env*` files are untracked (except approved templates).
+- Check `.gitignore` patterns include root and nested environment file variants.
+- Validate deployed systems use secure environment injection, not committed files.
+- Confirm rotated values are active and old credentials are invalid.
+- Review pull requests for accidental reintroduction of tracked env files.
+
+## False Positives and Exceptions
+- `.env.example` and `.env.template` are acceptable if they contain no real secrets.
+- Test fixtures may include fake credentials only when clearly non-operational.
+- Some repos intentionally track non-sensitive env files; exceptions need approval.
+- Emergency temporary commits are still violations unless formally exempted.
+
+## Related Rules
+- [TG-SEC-001](./TG-SEC-001-hardcoded-secrets.md) - Hardcoded secrets in source files
+- [TG-SEC-002](./TG-SEC-002-public-environment-secrets.md) - Secrets exposed through public env prefixes
+- [TG-SEC-004](./TG-SEC-004-sensitive-logging.md) - Runtime leakage through sensitive logging

package/skills/torusguard/payload/rules/active/TG-SEC-004-sensitive-logging.md

@@ -0,0 +1,83 @@
+# TG-SEC-004: Sensitive Information in Logs
+
+## Severity
+Medium
+
+## Applies To
+- Application logs in backend services, workers, and serverless functions
+- Client-side error logging and telemetry pipelines
+- Authentication middleware and API gateway handlers
+- Structured logs, plaintext logs, and third-party observability sinks
+
+## Why It Matters
+Logs are broadly distributed across systems, retained for long periods, and frequently accessible to many operators.  
+If passwords, tokens, cookies, or authorization headers are logged, sensitive data can be replayed or abused.  
+Log leakage often bypasses normal secret handling controls because it happens after request processing.
+
+## What TorusGuard Looks For
+- Direct logging of request bodies containing credentials
+- Logging of headers without redaction, especially `Authorization` and `Cookie`
+- Serialization of auth/session objects that include tokens
+- Error logs that concatenate secret values into exception messages
+- Debug statements printing plaintext passwords, OTP codes, or API keys
+
+## Unsafe Example
+```ts
+// src/middleware/login.ts
+export async function loginHandler(req, res) {
+  console.info("Login payload", req.body);
+  console.info("Auth header", req.headers.authorization);
+
+  const token = await issueToken(req.body.email);
+  console.debug(`issued token=${token}`);
+  return res.json({ ok: true });
+}
+```
+
+## Safe Example
+```ts
+// src/middleware/login.ts
+function redactAuthHeader(value?: string) {
+  if (!value) return "missing";
+  return value.startsWith("Bearer ") ? "Bearer [REDACTED]" : "[REDACTED]";
+}
+
+export async function loginHandler(req, res) {
+  console.info("Login attempt", {
+    emailDomain: req.body.email?.split("@")[1] ?? "unknown",
+    hasPassword: Boolean(req.body.password),
+    auth: redactAuthHeader(req.headers.authorization),
+  });
+
+  const token = await issueToken(req.body.email);
+  console.debug("Issued session token", { token: "[REDACTED]" });
+  return res.json({ ok: true });
+}
+```
+
+## Remediation (numbered)
+1. Remove direct logging of request bodies and sensitive headers.
+2. Implement centralized redaction for known secret fields and header keys.
+3. Log metadata and security-relevant context without raw secret values.
+4. Update logging wrappers to block unsafe keys by default.
+5. Rotate credentials if logs already captured valid sensitive data.
+6. Restrict log access and retention for security-sensitive services.
+7. Add automated tests to assert redaction behavior in logging utilities.
+
+## Verification
+- Search logging calls for `password`, `token`, `authorization`, and `cookie` fields.
+- Generate representative requests and inspect emitted logs for redaction.
+- Confirm tracing/telemetry exporters do not reintroduce sensitive attributes.
+- Validate historical logs for recent exposure and incident follow-up needs.
+- Ensure secure logging guidance is included in service development standards.
+
+## False Positives and Exceptions
+- Logging token hashes or irreversible fingerprints may be acceptable for correlation.
+- Masked values can still trigger detections; confirm full redaction depth.
+- Security incident forensics may require temporary enhanced logs under strict controls.
+- Exceptions must include expiration, owner, and explicit approval.
+
+## Related Rules
+- [TG-SEC-001](./TG-SEC-001-hardcoded-secrets.md) - Source-level hardcoded secret exposure
+- [TG-SEC-003](./TG-SEC-003-tracked-env-file.md) - Secret leakage through tracked env files
+- [TG-DB-002](./TG-DB-002-privileged-database-credential.md) - Privileged credentials exposed to clients