Unexpectedly broad result sets when Mongoose strictQuery strips unknown filter keys

Answer

Strip unknown filter keys at the schema layer only as a developer convenience, never as an authorization control. Pass them through to MongoDB and validate explicitly at the application layer. Pin strictQuery explicitly in every schema or connection rather than relying on version-sensitive defaults.

Likely explanation vs. confirmed behavior

The broad result sets are most likely caused by Mongoose removing filter keys that do not match a schema path during query casting. When strictQuery is true—the default in Mongoose 6 and later—a misspelled or unexpected field name is dropped before the command reaches MongoDB, so the remaining conditions match more documents than intended.

Confirmed across major versions: strictQuery was split from strict in Mongoose 6. In Mongoose 5, the single strict option governed both reads and writes and defaulted to true. In Mongoose 6+, strictQuery defaults to true while strict defaults to false. The option applies to find, findOne, count, update, and findOneAndUpdate.

Steps for this case

1. Pin the behavior explicitly. Set strictQuery at the connection or schema level so major upgrades do not silently change query semantics.

   // Connection level
   mongoose.set('strictQuery', false);
   
   // Schema level
   const userSchema = new Schema({ /* ... */ }, { strictQuery: false });

   Choose false if you want MongoDB to receive unknown keys and your application to validate them. Choose true only if you accept that unknown keys are silently dropped.
2. Validate inputs before casting. Build an allow-list of queryable fields and reject requests containing unknown keys. This prevents both over-broad results and accidental exposure of unmodeled data.
3. Verify the current behavior. Check the installed version with npm list mongoose. Log query._conditions or use query.getFilter() with a deliberately misspelled field to confirm whether it is stripped. Temporarily toggle strictQuery and compare result sizes.

Open question

If any schemas already use strict: false to store unmodeled fields, that changes the trade-off: strictQuery: false would pass those fields through on reads, while strict: true would strip them on writes. Do you have collections that intentionally store dynamic properties?