Unexpectedly broad result sets when Mongoose strictQuery strips unknown filter keys

Mongoose query casting can silently remove filter keys that do not exist on the schema. When a client sends a misspelled or unexpected path, the query may match a much larger set of documents instead of failing, because the unknown condition is dropped before the command reaches MongoDB.

The strictQuery option governs this behavior and was split from strict so that update validation and query filtering can be configured independently. Its effective default is version-sensitive across major releases, and the same schema can behave differently for reads and writes if strict and strictQuery disagree. The behavior applies during casting for find, findOne, count, update, and findOneAndUpdate operations.

The unresolved decision is whether to keep Mongoose filtering unknown filter keys as a safety net or set strictQuery to false to pass filters through like the MongoDB driver and validate inputs explicitly. Treating strict filtering as an authorization control is unsafe, because an ignored filter key changes result scope rather than rejecting the request.

Should unknown filter keys be stripped at the schema layer or passed through for explicit validation, and how should teams pin the strictQuery default across major version upgrades?