En pruebas de caja negra contra el entorno local (localhost:3000), cualquiera sin autenticarse puede crear un usuario con rol admin y luego iniciar sesión con él. POST /api/users está abierto (no exige sesión, #5) y acepta el campo role tal cual del body (mass assignment), así que no hace falta ninguna cuenta previa para obtener control total.
Entorno
local
Módulos
Auth / sesión / roles, API / backend, Usuarios
Severidad
Bloquea un flujo
Pasos para reproducir
Sin ninguna sesión ni token: curl -X POST localhost:3000/api/users -H 'Content-Type: application/json' -d '{"name":"x","email":"[email protected]","role":"admin","password":"p"}'
Respuesta 201 con el usuario creado y role: "admin".
curl -X POST localhost:3000/api/auth/login -H 'Content-Type: application/json' -d '{"id":<id creado>,"password":"p"}'
Respuesta 201 con el usuario admin: sesión iniciada.
Esperado
Crear usuarios requiere sesión de administrador.
El rol no se acepta desde un body sin autorización; un usuario no puede auto-asignarse admin.
Actual
Verificado en caja negra: se creó el usuario id 2 ([email protected], role: admin) sin sesión, con respuesta 201, y el login posterior devolvió 201 con ese admin. Cualquiera con acceso de red a la API obtiene control total del PDV.
Evidencia
Verificado en ejecución contra localhost:3000 el 2026-10-02.
POST /api/users {"role":"admin",...} → 201{"id":2,"role":"admin",...}
POST /api/auth/login {"id":2,"password":"p"} → 201{"id":2,"role":"admin",...}
Nota: quedó en la base un usuario de prueba id 2([email protected]) que hay que borrar.
Depende de #5 (ningún endpoint exige auth) y #4 (sin validación / mass assignment). El arreglo completo es: exigir sesión de admin en las rutas de usuarios, y en el registro/creación no tomar role del body sino fijarlo en el servidor.
¿Está también en producción?
Sí — este issue no basta; hay que abrir un Incidente / hotfix
No — solo local / staging
No sé
Antes de abrir
Busqué un issue duplicado
### Qué pasa
En pruebas de caja negra contra el entorno local (`localhost:3000`), cualquiera sin autenticarse puede **crear un usuario con rol `admin`** y luego iniciar sesión con él. `POST /api/users` está abierto (no exige sesión, #5) y acepta el campo `role` tal cual del body (mass assignment), así que no hace falta ninguna cuenta previa para obtener control total.
### Entorno
local
### Módulos
Auth / sesión / roles, API / backend, Usuarios
### Severidad
Bloquea un flujo
### Pasos para reproducir
1. Sin ninguna sesión ni token:
`curl -X POST localhost:3000/api/users -H 'Content-Type: application/json' -d '{"name":"x","email":"[email protected]","role":"admin","password":"p"}'`
2. Respuesta `201` con el usuario creado y `role: "admin"`.
3. `curl -X POST localhost:3000/api/auth/login -H 'Content-Type: application/json' -d '{"id":<id creado>,"password":"p"}'`
4. Respuesta `201` con el usuario admin: sesión iniciada.
### Esperado
- Crear usuarios requiere sesión de administrador.
- El rol no se acepta desde un body sin autorización; un usuario no puede auto-asignarse `admin`.
### Actual
Verificado en caja negra: se creó el usuario `id 2` (`[email protected]`, `role: admin`) sin sesión, con respuesta `201`, y el login posterior devolvió `201` con ese admin. Cualquiera con acceso de red a la API obtiene control total del PDV.
### Evidencia
```shell
Verificado en ejecución contra localhost:3000 el 2026-10-02.
POST /api/users {"role":"admin",...} → 201 {"id":2,"role":"admin",...}
POST /api/auth/login {"id":2,"password":"p"} → 201 {"id":2,"role":"admin",...}
Nota: quedó en la base un usuario de prueba id 2 ([email protected]) que hay que borrar.
```
Depende de #5 (ningún endpoint exige auth) y #4 (sin validación / mass assignment). El arreglo completo es: exigir sesión de admin en las rutas de usuarios, y en el registro/creación no tomar `role` del body sino fijarlo en el servidor.
### ¿Está también en producción?
- [ ] Sí — este issue no basta; hay que abrir un Incidente / hotfix
- [ ] No — solo local / staging
- [x] No sé
### Antes de abrir
- [x] Busqué un issue duplicado
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é pasa
En pruebas de caja negra contra el entorno local (
localhost:3000), cualquiera sin autenticarse puede crear un usuario con roladminy luego iniciar sesión con él.POST /api/usersestá abierto (no exige sesión, #5) y acepta el camporoletal cual del body (mass assignment), así que no hace falta ninguna cuenta previa para obtener control total.Entorno
local
Módulos
Auth / sesión / roles, API / backend, Usuarios
Severidad
Bloquea un flujo
Pasos para reproducir
curl -X POST localhost:3000/api/users -H 'Content-Type: application/json' -d '{"name":"x","email":"[email protected]","role":"admin","password":"p"}'201con el usuario creado yrole: "admin".curl -X POST localhost:3000/api/auth/login -H 'Content-Type: application/json' -d '{"id":<id creado>,"password":"p"}'201con el usuario admin: sesión iniciada.Esperado
admin.Actual
Verificado en caja negra: se creó el usuario
id 2([email protected],role: admin) sin sesión, con respuesta201, y el login posterior devolvió201con ese admin. Cualquiera con acceso de red a la API obtiene control total del PDV.Evidencia
Depende de #5 (ningún endpoint exige auth) y #4 (sin validación / mass assignment). El arreglo completo es: exigir sesión de admin en las rutas de usuarios, y en el registro/creación no tomar
roledel body sino fijarlo en el servidor.¿Está también en producción?
Antes de abrir