Los DTOs de apps/api/src/dtos son interface, que desaparecen al compilar, y no hay un ValidationPipe global. El API acepta cualquier payload.
Todo módulo expone CRUD genérico completo, incluidas operaciones que el dominio no permite:
PATCH /warehouses/:inventoryId/:productId edita el stock directamente, lo que contradice la regla de inventory-movement.service.ts:25-30 ("el stock nunca se edita directamente").
DELETE en payments, operating-days y cash-register-sessions puede borrar registros contables.
Qué estamos pagando hoy
Se pueden guardar valores inválidos (status: "lo-que-sea", quantity: "abc", montos negativos) que rompen reportes y filtros.
El stock y los registros de caja y pagos se pueden alterar sin dejar rastro en inventory_movement ni cash_movement.
Arreglo propuesto
ValidationPipe global (whitelist, forbidNonWhitelisted, transform) con DTOs de clase (class-validator) o esquemas zod, usando los enums del contrato (#2).
Quitar los endpoints que el dominio no permite.
Validación global de entrada
DTOs validados para todos los controllers
Eliminar PATCH /warehouses y los DELETE contables
Techo de esta ronda
Validación de forma y tipos, y retiro de endpoints peligrosos. Fuera: reglas de negocio transaccionales (#3) y control de acceso por rol (#5).
Superficie
API (apps/api)
Módulos
API / backend, Inventario / almacenes, Caja / sesiones de caja, Día de operación
Esfuerzo
M — un PR, un día
Riesgo de no tocarlo
Alto (seguridad, datos, o bloquea el próximo corte)
### Qué es la deuda
- Los DTOs de `apps/api/src/dtos` son `interface`, que desaparecen al compilar, y no hay un `ValidationPipe` global. El API acepta cualquier payload.
- Todo módulo expone CRUD genérico completo, incluidas operaciones que el dominio no permite:
- `PATCH /warehouses/:inventoryId/:productId` edita el stock directamente, lo que contradice la regla de `inventory-movement.service.ts:25-30` ("el stock nunca se edita directamente").
- `DELETE` en `payments`, `operating-days` y `cash-register-sessions` puede borrar registros contables.
### Qué estamos pagando hoy
- Se pueden guardar valores inválidos (`status: "lo-que-sea"`, `quantity: "abc"`, montos negativos) que rompen reportes y filtros.
- El stock y los registros de caja y pagos se pueden alterar sin dejar rastro en `inventory_movement` ni `cash_movement`.
### Arreglo propuesto
- `ValidationPipe` global (`whitelist`, `forbidNonWhitelisted`, `transform`) con DTOs de clase (`class-validator`) o esquemas `zod`, usando los enums del contrato (#2).
- Quitar los endpoints que el dominio no permite.
- [ ] Validación global de entrada
- [ ] DTOs validados para todos los controllers
- [ ] Eliminar `PATCH /warehouses` y los `DELETE` contables
### Techo de esta ronda
Validación de forma y tipos, y retiro de endpoints peligrosos. Fuera: reglas de negocio transaccionales (#3) y control de acceso por rol (#5).
### Superficie
API (apps/api)
### Módulos
API / backend, Inventario / almacenes, Caja / sesiones de caja, Día de operación
### Esfuerzo
M — un PR, un día
### Riesgo de no tocarlo
Alto (seguridad, datos, o bloquea el próximo corte)
Carlos
changed title from Validación de entrada (ValidationPipe) y quitar endpoints CRUD peligrosos to [debt] Validación de entrada (ValidationPipe) y quitar endpoints CRUD peligrosos2026-10-02 17:42:57 +00:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Qué es la deuda
apps/api/src/dtossoninterface, que desaparecen al compilar, y no hay unValidationPipeglobal. El API acepta cualquier payload.PATCH /warehouses/:inventoryId/:productIdedita el stock directamente, lo que contradice la regla deinventory-movement.service.ts:25-30("el stock nunca se edita directamente").DELETEenpayments,operating-daysycash-register-sessionspuede borrar registros contables.Qué estamos pagando hoy
status: "lo-que-sea",quantity: "abc", montos negativos) que rompen reportes y filtros.inventory_movementnicash_movement.Arreglo propuesto
ValidationPipeglobal (whitelist,forbidNonWhitelisted,transform) con DTOs de clase (class-validator) o esquemaszod, usando los enums del contrato (#2).Quitar los endpoints que el dominio no permite.
Validación global de entrada
DTOs validados para todos los controllers
Eliminar
PATCH /warehousesy losDELETEcontablesTecho de esta ronda
Validación de forma y tipos, y retiro de endpoints peligrosos. Fuera: reglas de negocio transaccionales (#3) y control de acceso por rol (#5).
Superficie
API (apps/api)
Módulos
API / backend, Inventario / almacenes, Caja / sesiones de caja, Día de operación
Esfuerzo
M — un PR, un día
Riesgo de no tocarlo
Alto (seguridad, datos, o bloquea el próximo corte)
Validación de entrada (ValidationPipe) y quitar endpoints CRUD peligrososto [debt] Validación de entrada (ValidationPipe) y quitar endpoints CRUD peligrososNo debemos depender de class-validator, en su lugar ocupar la capa validator de JS.
Lograrlo a traves de middlewares