`@omit` can be bypassed by explicit `select`

[Azzerty23]

Description

Fields marked with @omit are correctly stripped from query results in the default case, but an explicit select on the omitted field bypasses the protection and returns the field's value.

This defeats the security guarantee of @omit, which is most commonly used for sensitive fields like password hashes.

Example

model User {
  id           String @id @default(cuid())
  email        String @unique
  passwordHash String @omit
}

// ✅ Works as expected — passwordHash is omitted
await db.user.findFirst({ where: { email } });
// => { id, email }

// ❌ Bypasses @omit — passwordHash is returned
await db.user.findFirst({
  where: { email },
  select: { passwordHash: true },
});
// => { passwordHash: "$2a$12$..." }

Reproduction

https://stackblitz.com/~/github.com/Azzerty23/v3-doc-quick-start/tree/Azzerty23/zenstack-omit-issue

Expected behavior

@omit should be enforced regardless of how the field is requested. An explicit select (or include) targeting an omitted field should either:

• silently strip the field from the result, or
• throw a validation error at query time.

Actual behavior

The explicit select takes precedence and the omitted field is returned.

Environment

• ZenStack version: 3.7.0

[caiotarifa]

I think this behavior is expected: @omit only controls omission from the default returned shape. It should not be treated as an access-control rule.

If the goal is to actually prevent the field from being read, the right approach is to use an inline @deny rule on the field, for example:

model User {
  id       String @id @default(cuid())
  email    String
  password String @omit @deny('read', true)
}

[sanny-io]

Yes, this seems expected. @Azzerty23 you can disallow query-level selections of omitted fields, which will error if attempted to be selected.

const db = new ZenStackClient<Schema>({
  ...
  allowQueryTimeOmitOverride: false,
});

https://zenstack.dev/docs/orm/api/omit#precedence-and-overrides

[Azzerty23]

Thank you for your answers. For context, I'm using this with an MCP that builds queries on its own.

I was surprised when I saw my MCP returning passwords that are usually hidden with @omit ^^

I wasn't aware of allowQueryTimeOmitOverride, and I honestly didn't expect the MCP to be able to bypass omit at the query level. In this context, I have no other choice than using field-level policies.

For the record, even setting allowQueryTimeOmitOverride to false doesn't prevent omitted fields from leaking when using select — I just tested it on the repro.

From my understanding of the docs, schema-level omit can be overridden by explicitly passing omit: false.

await db.user.findMany({
  omit: { password: false },
});

I still think the intention is very different from:

await db.user.findMany({
  select: { password: true },
});

Do you know how this works with Prisma? I was surprised to see an example in their docs that includes a password field. It looks safe, but it actually isn’t.

[sanny-io]

The docs specifically mention that the option can be used for security, but if that is the case, I think this is a bug, or at least the docs should be updated.

I don't know how it works in Prisma, but ZenStack is a full-stack a library rather than a backend-only one. It is expected that end-users are able to manipulate payloads. If they can select an omitted field when allowQueryTimeOmitOverride is set to false, that doesn't sound secure.