analytics: /analytics/query echoes the executed SQL in production (NODE_ENV=production, no debug requested) — schema documents it as debug-only

[baozhoutao]

POST /api/v1/analytics/query returns the executed SQL to the caller on a deployment running NODE_ENV=production, with no debug flag requested.

Repro

Request (no debug field of any kind):

{ "cube": "sys_user", "measures": ["count"], "dimensions": [] }

Response:

{ "success": true, "data": {
 "rows": [{ "count": "2" }],
 "fields": [{ "name": "count", "type": "number" }],
 "sql": "SELECT COUNT(*) AS \"count\" FROM \"sys_user\" WHERE ((\"sys_user\".\"id\" = $1 OR \"sys_user\".\"id\" IN ($2, $3) OR \"sys_user\".\"id\" = $4 …"
} }

Container environment of the serving app (objectos-ee-deploy-app-1):

NODE_ENV=production
OS_TENANCY_POSTURE=isolated
OS_MODE=standalone

Expected

The contract already says this is debug-gated — packages/spec/src/api/analytics.zod.ts:75:

sql: z.string().optional().describe('Executed SQL (if debug enabled)'),

Nothing in the request enabled debug, and the deployment is production, so sql should be absent.

Why it matters here specifically

The echoed statement discloses the physical table name, the column naming, and — most sensitive on a multi-tenant deployment — the shape of the isolation predicate itself. In this case it reveals that sys_user is walled by an enumerated id IN (…) member list rather than an organization_id comparison, i.e. it tells a tenant exactly how (and on which column) the wall is built, plus the bound-parameter arity, which leaks the rough member count of their own org and the query surface to probe against.

This is an information-disclosure issue, not a broken wall: every isolation probe I ran on this deployment held (cross-tenant read → 404, cross-tenant update/delete → 403 row-level security, filter/where naming another org → empty, batch update/delete by foreign id → per-row PERMISSION_DENIED, audit log and activity stream partitioned cleanly). The wall is fine; it just should not describe itself to callers.

Suggested fix

Gate the sql field on the same debug switch the schema documents, and default it off outside development — or drop it from the response entirely and keep SQL echo on the dedicated /api/v1/analytics/sql dry-run route (analytics.zod.ts:23), which is the surface that exists for it.

Environment

objectos-ee-deploy stack (Caddy → app → postgres:16) on http://localhost:8080, observed 2026-08-13, org owner session. Image commit not verified; spec references are the current framework main checkout.

[hotlong]

Triage: pm:queue, domain:services, security added, type Bug. Two label corrections: removed self-made domain:access-security (not a lane; the label authority is the triage seat — standing instruction, 2026-08-12) and the filer's priority:p2 (p1–p5 ladder retired, no reader).

Landing pinned at triage (anchoring rule): the echo's producer is packages/services/service-analytics/src/strategies/native-sql-strategy.ts:274 — return { rows, fields, sql }, unconditional. The contract cite (packages/spec/src/api/analytics.zod.ts:75, "Executed SQL (if debug enabled)") is the declared behavior; the fix restores declared = enforced by gating sql on the debug switch (or dropping it in favor of the dedicated /analytics/sql dry-run route, per the card). This does not change the acceptance surface — it narrows an over-serving response to its documented shape — so it is a Bug, not a decision card.

Dispatch notes:

• packages/services/service-analytics/src/__tests__/cross-field-engine-fallback.test.ts:469 already pins "sql must be absent" for the engine-fallback path — extend that pin family to the non-debug production path; assert absence, not just falsiness.
• Check the other strategies (analytics-service.ts fallback delegate at ~:2137 mints a sql string too) so the gate lands at the response-assembly seam, not per-strategy — one gate, all strategies.
• The NativeSQL always includes sql expectation at analytics-service.test.ts:429 will need to become debug-conditioned — that test asserts the current defect.
• Security framing per the card: information disclosure only (isolation held on all probes); no incident process needed, but the changeset should say what was disclosed.

Size/model suggestion: S–M, mode:subagent, opus.

---

Generated by Claude Code