torusguard 1.0.0 → 1.3.1

package/.torusguard/rules/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/.torusguard/rules/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/.torusguard/rules/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/.torusguard/rules/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

package/.torusguard/rules/active/TG-AUTH-001-weak-password-storage.md

@@ -0,0 +1,103 @@
+# TG-AUTH-001: Weak Password Storage
+
+## Severity
+Critical
+
+## Applies To
+- User registration and login systems
+- Password reset and credential update flows
+- Legacy account import/migration jobs
+- Identity providers that store local credentials
+
+## Why It Matters
+Weak password storage enables catastrophic compromise when databases leak through attacks, backups, logs, or insider misuse.
+Plaintext, reversible encryption, or fast unsalted hashes let attackers recover passwords quickly and reuse them across services.
+Secure, adaptive hashing with per-password salt and optional pepper drastically reduces offline cracking feasibility.
+
+## What TorusGuard Looks For
+- Passwords stored as plaintext or encoded forms such as Base64.
+- Use of outdated fast hashes (`MD5`, `SHA1`, bare `SHA256`) for password storage.
+- Same hash value for identical passwords due to missing random salt.
+- Manual cryptography routines instead of vetted password hashing libraries.
+- Logging of raw passwords or hash inputs during authentication workflows.
+
+## Unsafe Example
+```js
+import crypto from "crypto";
+
+app.post("/api/register", async (req, res) => {
+  const email = req.body.email;
+  const password = req.body.password;
+
+  // Fast hash with no salt and no work factor
+  const passwordHash = crypto.createHash("sha256").update(password).digest("hex");
+
+  await db.user.create({
+    data: { email, password_hash: passwordHash }
+  });
+
+  res.json({ ok: true });
+});
+```
+
+## Safe Example
+```js
+import argon2 from "argon2";
+
+app.post("/api/register", async (req, res) => {
+  const email = String(req.body.email || "");
+  const password = String(req.body.password || "");
+
+  if (password.length < 12) {
+    return res.status(400).json({ ok: false, error: "Password too short" });
+  }
+
+  const hash = await argon2.hash(password, {
+    type: argon2.argon2id,
+    memoryCost: 19456,
+    timeCost: 2,
+    parallelism: 1
+  });
+
+  await db.user.create({
+    data: { email, password_hash: hash }
+  });
+
+  res.json({ ok: true });
+});
+
+app.post("/api/login", async (req, res) => {
+  const user = await db.user.findUnique({ where: { email: req.body.email } });
+  if (!user) return res.status(401).json({ ok: false });
+
+  const valid = await argon2.verify(user.password_hash, String(req.body.password || ""));
+  if (!valid) return res.status(401).json({ ok: false });
+
+  res.json({ ok: true });
+});
+```
+
+## Remediation
+1. Replace insecure password storage with Argon2id, bcrypt, or scrypt using recommended cost factors.
+2. Ensure each password hash includes a unique random salt (handled by modern libraries).
+3. Add optional application-level pepper stored in a secret manager, not in the database.
+4. Remove password values from logs, traces, analytics events, and error telemetry.
+5. Migrate existing hashes using rehash-on-login or controlled reset campaigns.
+6. Periodically tune work factors based on current hardware and latency targets.
+
+## Verification
+- Inspect stored credential records and confirm they use adaptive hash formats.
+- Verify identical passwords across test accounts produce different hash outputs.
+- Benchmark login flow to ensure configured cost factors are actually applied.
+- Attempt cracking tests on sample exported hashes to validate resistance assumptions.
+- Review codebase for direct use of fast hash APIs in authentication modules.
+
+## False Positives and Exceptions
+- One-way hashes for non-password tokens may look similar but are separate controls.
+- Temporary test fixtures can include static hashes only if isolated from production data paths.
+- External identity providers reduce local password handling scope but do not exempt backup credential paths.
+
+## Related Rules
+- [TG-AUTH-005](./TG-AUTH-005-unsafe-password-reset.md)
+- [TG-AUTH-004](./TG-AUTH-004-insecure-session-cookie.md)
+- [TG-INPUT-001](./TG-INPUT-001-missing-server-validation.md)

package/.torusguard/rules/active/TG-AUTH-002-client-only-authorization.md

@@ -0,0 +1,85 @@
+# TG-AUTH-002: Client-Only Authorization
+
+## Severity
+High
+
+## Applies To
+- Single-page applications with protected routes
+- Mobile apps that hide privileged UI actions
+- APIs serving both user and admin clients
+- Feature-flagged operations with role constraints
+
+## Why It Matters
+Authorization enforced only in frontend code is not security control, because attackers can bypass the UI and call backend APIs directly.
+If server endpoints trust client-supplied role flags or hidden form fields, privilege escalation becomes trivial.
+Robust authorization must be verified on every sensitive backend action regardless of UI behavior.
+
+## What TorusGuard Looks For
+- Admin checks present in frontend components but absent in backend handlers.
+- API routes that trust `role`, `isAdmin`, or similar flags from request body/query.
+- Hidden buttons/menus used as the only barrier to privileged operations.
+- Use of local storage role values for security decisions.
+- Missing middleware or policy checks around destructive and high-impact endpoints.
+
+## Unsafe Example
+```js
+// Frontend blocks non-admin users from seeing delete button
+if (currentUser.role === "admin") {
+  showDeleteUserButton();
+}
+
+// Backend route does not verify authenticated role
+app.post("/api/admin/delete-user", async (req, res) => {
+  const targetUserId = req.body.userId;
+  await db.user.delete({ where: { id: targetUserId } });
+  res.json({ ok: true });
+});
+```
+
+## Safe Example
+```js
+function requireRole(...allowedRoles) {
+  return (req, res, next) => {
+    const role = req.auth?.role;
+    if (!allowedRoles.includes(role)) {
+      return res.status(403).json({ ok: false, error: "Forbidden" });
+    }
+    next();
+  };
+}
+
+app.post("/api/admin/delete-user", requireAuth, requireRole("admin"), async (req, res) => {
+  const targetUserId = String(req.body.userId || "");
+  if (!/^[a-f0-9-]{36}$/.test(targetUserId)) {
+    return res.status(400).json({ ok: false, error: "Invalid user id" });
+  }
+
+  await db.user.delete({ where: { id: targetUserId } });
+  res.json({ ok: true });
+});
+```
+
+## Remediation
+1. Enforce authorization checks on the server for every protected action and resource.
+2. Derive roles/permissions from authenticated server-side identity, not request payload flags.
+3. Implement centralized policy middleware to reduce inconsistent endpoint protection.
+4. Keep frontend role checks for UX only, never as the sole security mechanism.
+5. Add audit logging for privileged operations including actor, target, and outcome.
+6. Write regression tests that call endpoints directly without using the UI.
+
+## Verification
+- Call privileged endpoints with a non-admin token and verify consistent `403` responses.
+- Remove/hide frontend restrictions in browser devtools and confirm backend still blocks access.
+- Attempt sending forged `isAdmin: true` fields and verify they are ignored.
+- Inspect route registrations to ensure protected middleware is applied universally.
+- Review audit logs for denied authorization attempts.
+
+## False Positives and Exceptions
+- Public metadata endpoints may intentionally skip authorization if they contain no sensitive operations or data.
+- Early prototypes often rely on frontend checks; production deployment must not.
+- Internal admin APIs still require authorization controls unless isolated by strong network identity boundaries.
+
+## Related Rules
+- [TG-AUTH-003](./TG-AUTH-003-missing-object-authorization.md)
+- [TG-AUTH-004](./TG-AUTH-004-insecure-session-cookie.md)
+- [TG-INPUT-001](./TG-INPUT-001-missing-server-validation.md)

package/.torusguard/rules/active/TG-AUTH-003-missing-object-authorization.md

@@ -0,0 +1,85 @@
+# TG-AUTH-003: Missing Object-Level Authorization (IDOR)
+
+## Severity
+High
+
+## Applies To
+- APIs that fetch or modify records by ID
+- File and document retrieval endpoints
+- Multi-tenant systems with organization-scoped data
+- Billing, messaging, and profile management resources
+
+## Why It Matters
+IDOR occurs when applications expose object identifiers but fail to verify that the requester is allowed to access that specific object.
+Attackers can enumerate or guess IDs to read, modify, or delete other users' resources without needing elevated roles.
+This creates severe confidentiality and integrity breaches, especially in multi-tenant products.
+
+## What TorusGuard Looks For
+- Endpoints reading `:id` or query IDs without ownership or tenant checks.
+- `findUnique`/`getById` calls that do not include current user or tenant constraints.
+- Access to files/records based solely on untrusted identifier parameters.
+- Sequential numeric IDs exposed in URLs with missing authorization guards.
+- Update/delete operations that authenticate user identity but skip object-level policy.
+
+## Unsafe Example
+```js
+app.get("/api/invoices/:invoiceId", requireAuth, async (req, res) => {
+  const invoiceId = req.params.invoiceId;
+
+  // Authenticated, but no check that invoice belongs to this user/tenant
+  const invoice = await db.invoice.findUnique({
+    where: { id: invoiceId }
+  });
+
+  if (!invoice) return res.status(404).json({ ok: false });
+  res.json({ ok: true, invoice });
+});
+```
+
+## Safe Example
+```js
+app.get("/api/invoices/:invoiceId", requireAuth, async (req, res) => {
+  const invoiceId = String(req.params.invoiceId || "");
+  const userId = req.auth.userId;
+  const tenantId = req.auth.tenantId;
+
+  const invoice = await db.invoice.findFirst({
+    where: {
+      id: invoiceId,
+      tenant_id: tenantId,
+      customer_user_id: userId
+    }
+  });
+
+  if (!invoice) {
+    return res.status(404).json({ ok: false, error: "Not found" });
+  }
+
+  res.json({ ok: true, invoice });
+});
+```
+
+## Remediation
+1. Apply object-level authorization checks on every read, update, and delete path.
+2. Scope data queries by authenticated user, tenant, account, or policy context.
+3. Centralize authorization policies so object checks are consistent across endpoints.
+4. Avoid exposing predictable identifiers when not required; consider opaque IDs.
+5. Log access denials and anomalous ID probing attempts for detection.
+6. Add tests that attempt cross-user and cross-tenant access with valid credentials.
+
+## Verification
+- Authenticate as User A and request User B resources by changing IDs.
+- Confirm unauthorized object access returns `404` or `403` consistently without data leakage.
+- Test update and delete endpoints, not only read endpoints.
+- Validate background jobs and export endpoints enforce tenant/object constraints too.
+- Inspect ORM/database queries for required ownership predicates.
+
+## False Positives and Exceptions
+- Public resources intentionally shared across tenants should be explicitly labeled and policy-reviewed.
+- Some administrative roles can access cross-tenant objects, but this must be explicit and auditable.
+- Random UUID usage alone does not remove need for object authorization.
+
+## Related Rules
+- [TG-AUTH-002](./TG-AUTH-002-client-only-authorization.md)
+- [TG-INPUT-001](./TG-INPUT-001-missing-server-validation.md)
+- [TG-INPUT-002](./TG-INPUT-002-raw-sql-concatenation.md)