MongoDB
Explica cómo entradas no confiables pueden convertirse en operadores MongoDB y cómo prevenir inyección mediante validación, allowlists y consultas construidas en servidor.
MongoDB queries son objetos estructurados, no strings SQL. Eso evita una clase de SQL injection, pero introduce operator injection: un atacante puede enviar claves como $ne, $gt, $regex o estructuras inesperadas si la aplicación copia input directamente al filtro o update.
// peligroso
const user = await users.findOne(req.body);Payload:
{
"email": { "$ne": null },
"password": { "$ne": null }
}El problema no es MongoDB: la aplicación entregó control sobre la estructura de la consulta.
Extrae valores escalares y construye el filtro:
const input = loginSchema.parse(req.body);
const user = await users.findOne({
normalizedEmail: normalizeEmail(input.email)
});La validación runtime es obligatoria. TypeScript desaparece en ejecución y no valida JSON recibido.
Para filtros dinámicos, define campos y operadores permitidos:
const allowedSorts = {
newest: { createdAt: -1 as const, _id: -1 as const },
oldest: { createdAt: 1 as const, _id: 1 as const }
};
const sort = allowedSorts[input.sort] ?? allowedSorts.newest;Nunca aceptes directamente:
collection.find(filter).sort(req.body.sort);Este patrón permite modificar campos protegidos:
await users.updateOne(
{ _id: userId },
{ $set: req.body }
);Construye un DTO explícito:
const update: UpdateFilter<UserDocument> = {
$set: {
displayName: input.displayName,
locale: input.locale,
updatedAt: new Date()
}
};No permitas cambiar role, businessId, passwordHash, balances o estados internos salvo en casos de uso autorizados.
Objetos no confiables pueden incluir claves que empiezan por $ o contienen .. Aunque drivers y ODMs aplican restricciones y sanitización en algunos contextos, no debes depender de defaults que cambian entre versiones.
Rechaza claves desconocidas y utiliza schemas strict.
Una regex creada por usuario puede consumir CPU o impedir índices:
{ name: { $regex: input.query, $options: 'i' } }Defensas:
maxTimeMS;Pipelines dinámicos también son código de consulta. Nunca aceptes stages completos desde una request:
// peligroso
collection.aggregate(req.body.pipeline);Construye stages en servidor y permite solo parámetros escalares. Protege especialmente $lookup, $out, $merge, $function, expresiones JavaScript y namespaces.
Una projection controlada por el cliente puede exponer secretos:
// peligroso
findOne(filter, { projection: req.query.fields });Define DTOs de salida y excluye campos sensibles incluso si el usuario solicita *.
Toda query debe incluir scope derivado de la sesión, nunca del body:
const order = await orders.findOne({
_id: new ObjectId(input.id),
businessId: auth.businessId
});No uses businessId enviado por el cliente como autorización. En $lookup, updates, deletes y aggregations, aplica el tenant en todas las ramas relevantes.
Valida formato y convierte explícitamente:
if (!ObjectId.isValid(input.id)) {
throw new BadRequestError('Invalid id');
}String y ObjectId no coinciden. Evita castings silenciosos que conviertan errores en queries amplias o excepciones inesperadas.
El usuario no debe controlar recursos sin límites:
limit con máximo;$in;const limit = Math.min(Math.max(input.limit ?? 20, 1), 100);Mongoose casting, strict, sanitizeFilter y validators pueden ayudar, pero no reemplazan:
Además, update validators no siempre se ejecutan igual que document validation; configura y prueba cada operación.
Evita ejecutar código proporcionado por usuarios en expresiones o funciones server-side. No construyas $where ni $function con input. Además del riesgo de seguridad, suele ser difícil de indexar y operar.
No registres filtros completos si contienen:
Registra query shape, campos permitidos, duración, tenant ID técnico y operation ID.
Prueba payloads:
{ "email": { "$gt": "" } }
{ "$where": "..." }
{ "role": "admin" }
{ "businessId": "otro-tenant" }
{ "name": { "$regex": "(a+)+$" } }El resultado debe ser rechazo de validación, no una query modificada.
$in con miles de valores;req.body;$in, sort y pagination.NoSQL no significa injection-free. El riesgo aparece cuando el cliente controla la estructura de filtros, updates, pipelines, sort o projection. La defensa es validar runtime, usar allowlists, construir consultas campo por campo y derivar autorización del servidor, no del payload.
Backups y restauración.