torusguard 1.3.0 → 1.3.1

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)

package/.torusguard/rules/active/TG-AUTH-004-insecure-session-cookie.md

@@ -0,0 +1,96 @@
+# TG-AUTH-004: Insecure Session Cookie Configuration
+
+## Severity
+High
+
+## Applies To
+- Web applications using cookie-based sessions
+- Authentication gateways and reverse proxies
+- Legacy apps migrating from token storage in local storage
+- SSO callback handlers setting auth cookies
+
+## Why It Matters
+Session cookies that lack secure attributes can be stolen, replayed, or manipulated by attackers.
+Missing `HttpOnly` enables JavaScript access during XSS, missing `Secure` exposes cookies over unencrypted transport, and weak `SameSite` settings increase CSRF risk.
+Improper domain/path/lifetime settings also expand token exposure across subdomains and long time windows.
+
+## What TorusGuard Looks For
+- Cookies set without `HttpOnly`, `Secure`, or explicit `SameSite`.
+- Session identifiers in URL parameters or local storage instead of hardened cookies.
+- Excessive cookie lifetime for sensitive sessions.
+- Broad cookie domain scopes (`.example.com`) without necessity.
+- Session rotation missing after login, privilege change, or password reset.
+
+## Unsafe Example
+```js
+app.post("/api/login", async (req, res) => {
+  const sessionId = await createSession(req.body.email, req.body.password);
+  if (!sessionId) return res.status(401).json({ ok: false });
+
+  // Missing critical security attributes
+  res.cookie("sid", sessionId, {
+    sameSite: "none"
+  });
+
+  res.json({ ok: true });
+});
+```
+
+## Safe Example
+```js
+app.post("/api/login", async (req, res) => {
+  const user = await verifyCredentials(req.body.email, req.body.password);
+  if (!user) return res.status(401).json({ ok: false });
+
+  const sessionId = await createSession(user.id);
+  res.cookie("sid", sessionId, {
+    httpOnly: true,
+    secure: true,
+    sameSite: "lax",
+    path: "/",
+    maxAge: 1000 * 60 * 30 // 30 minutes
+  });
+
+  res.json({ ok: true });
+});
+
+app.post("/api/password/reset/complete", requireAuth, async (req, res) => {
+  await invalidateAllSessions(req.auth.userId);
+  const rotated = await createSession(req.auth.userId);
+
+  res.cookie("sid", rotated, {
+    httpOnly: true,
+    secure: true,
+    sameSite: "strict",
+    path: "/",
+    maxAge: 1000 * 60 * 15
+  });
+
+  res.json({ ok: true });
+});
+```
+
+## Remediation
+1. Set `HttpOnly`, `Secure`, and explicit `SameSite` on all session/auth cookies.
+2. Use HTTPS everywhere; reject insecure origins and mixed-content session transport.
+3. Minimize cookie scope with narrow domain/path and reasonable expiration.
+4. Rotate session IDs on authentication, privilege transitions, and credential recovery.
+5. Invalidate old sessions on logout, password changes, and suspicious activity.
+6. Add CSRF protections compatible with cookie strategy for state-changing requests.
+
+## Verification
+- Inspect `Set-Cookie` headers in browser/network tools for required attributes.
+- Attempt JavaScript cookie reads and confirm auth cookies are inaccessible.
+- Test login over HTTP in non-production environments and ensure secure policy behavior.
+- Validate old session IDs stop working after rotation events.
+- Confirm cross-site POST attempts are blocked by SameSite and CSRF controls.
+
+## False Positives and Exceptions
+- `SameSite=None` can be valid for specific cross-site SSO flows, but requires `Secure` and additional CSRF controls.
+- Development environments on localhost may need adjusted secure handling; document separation from production settings.
+- Stateless bearer tokens in headers are out of scope for this rule but require equivalent protections.
+
+## Related Rules
+- [TG-AUTH-002](./TG-AUTH-002-client-only-authorization.md)
+- [TG-AUTH-005](./TG-AUTH-005-unsafe-password-reset.md)
+- [TG-INPUT-003](./TG-INPUT-003-unsafe-html-or-code-execution.md)

package/.torusguard/rules/active/TG-AUTH-005-unsafe-password-reset.md

@@ -0,0 +1,104 @@
+# TG-AUTH-005: Unsafe Password Reset Flow
+
+## Severity
+High
+
+## Applies To
+- "Forgot password" and account recovery endpoints
+- Email/SMS reset token issuance and verification
+- Self-service credential recovery in web and mobile apps
+- Administrative reset tooling for user accounts
+
+## Why It Matters
+Password reset is a high-value account takeover target because it bypasses existing credentials.
+Weak reset token generation, leakage through URLs/logs, missing expiry, and lack of rate limiting can let attackers hijack accounts at scale.
+Unsafe reset completion logic can also leave existing sessions active, preserving attacker access.
+
+## What TorusGuard Looks For
+- Predictable reset tokens or short numeric codes without brute-force protection.
+- Reset tokens stored in plaintext and compared directly.
+- Missing token expiry, single-use enforcement, or account binding checks.
+- User enumeration through distinct responses for existing vs non-existing emails.
+- Failure to invalidate active sessions after successful password reset.
+
+## Unsafe Example
+```js
+app.post("/api/password/forgot", async (req, res) => {
+  const user = await db.user.findUnique({ where: { email: req.body.email } });
+  if (!user) return res.status(404).json({ ok: false, error: "No account found" });
+
+  const token = Math.floor(Math.random() * 1000000).toString();
+  await db.password_reset.create({
+    data: { user_id: user.id, token, expires_at: null, used: false }
+  });
+
+  await sendMail(user.email, `Reset link: https://app.example/reset?token=${token}`);
+  res.json({ ok: true });
+});
+```
+
+## Safe Example
+```js
+import crypto from "crypto";
+
+app.post("/api/password/forgot", async (req, res) => {
+  const email = String(req.body.email || "").toLowerCase();
+  const user = await db.user.findUnique({ where: { email } });
+
+  // Always return generic response to prevent user enumeration
+  if (user) {
+    const rawToken = crypto.randomBytes(32).toString("hex");
+    const tokenHash = crypto.createHash("sha256").update(rawToken).digest("hex");
+    const expiresAt = new Date(Date.now() + 15 * 60 * 1000);
+
+    await db.password_reset.create({
+      data: { user_id: user.id, token_hash: tokenHash, expires_at: expiresAt, used: false }
+    });
+
+    await sendMail(user.email, `Reset link: https://app.example/reset?token=${rawToken}`);
+  }
+
+  res.json({ ok: true, message: "If an account exists, a reset email has been sent." });
+});
+
+app.post("/api/password/reset", async (req, res) => {
+  const rawToken = String(req.body.token || "");
+  const newPassword = String(req.body.newPassword || "");
+  const tokenHash = crypto.createHash("sha256").update(rawToken).digest("hex");
+
+  const record = await db.password_reset.findFirst({
+    where: { token_hash: tokenHash, used: false, expires_at: { gt: new Date() } }
+  });
+  if (!record) return res.status(400).json({ ok: false, error: "Invalid or expired token" });
+
+  await setUserPassword(record.user_id, newPassword);
+  await db.password_reset.update({ where: { id: record.id }, data: { used: true } });
+  await invalidateAllSessions(record.user_id);
+  res.json({ ok: true });
+});
+```
+
+## Remediation
+1. Generate cryptographically strong, high-entropy reset tokens and store only token hashes.
+2. Enforce short token lifetime, one-time use, and strict account binding.
+3. Apply rate limits and anomaly detection on reset request and token verification endpoints.
+4. Return generic responses for reset initiation to prevent account enumeration.
+5. Invalidate active sessions and recovery artifacts after successful password reset.
+6. Require strong new passwords and optionally step-up verification for risky reset attempts.
+
+## Verification
+- Request reset for known and unknown emails; verify indistinguishable responses.
+- Attempt brute-force token guesses and confirm lockout/rate-limit behavior.
+- Reuse a consumed token and confirm it fails.
+- Use an expired token and verify rejection path.
+- Confirm all existing sessions are invalidated after reset completion.
+
+## False Positives and Exceptions
+- Enterprise SSO environments may delegate password reset externally; local reset flows should be disabled or strongly gated.
+- Short OTP codes can be acceptable when combined with strict attempt limits, device binding, and very short expiry.
+- Manual support resets need controlled operator workflows and audit trails.
+
+## Related Rules
+- [TG-AUTH-001](./TG-AUTH-001-weak-password-storage.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-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/active/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/active/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