torusguard 1.0.0 → 1.3.1

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

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