Saltar a contenido

Security Checklist por Feature

Proposito

Checklist practico para revisar la seguridad de cada feature antes de hacer merge. No reemplaza un threat model completo, pero captura los errores mas comunes.

Cuando usarlo

  • En cada PR que introduce una feature nueva.
  • Antes de deployar a produccion.
  • Como parte del code review.

1. Autenticacion

  • Los endpoints protegidos requieren token valido (JWT verificado).
  • Los tokens se validan en CADA request (no solo en login).
  • El access token tiene expiracion corta (< 15 min).
  • El refresh token se almacena de forma segura (httpOnly cookie o BD).
  • Los passwords se hashean con bcrypt (cost >= 12), nunca en plaintext.
  • Los mensajes de error no revelan si un email existe ("Credenciales invalidas", no "Password incorrecto").
  • Hay rate limiting en endpoints de login y registro.
  • Hay bloqueo temporal despues de N intentos fallidos.

2. Autorizacion

  • Cada endpoint valida que el usuario tiene el ROL correcto.
  • Los usuarios solo pueden acceder a SUS propios recursos (un paciente no puede ver bookings de otro).
  • Los IDs en URLs no permiten acceso horizontal (cambiar :bookingId no da acceso a otro booking).
  • Los endpoints de admin estan protegidos con role guard.
  • No se confia en datos del cliente para determinar permisos (el role viene del JWT del server, no de un header del cliente).

3. Input Validation

  • Todos los inputs se validan en el servidor (no confiar en validacion del frontend).
  • Se usa validacion estricta de tipos (class-validator, zod, joi).
  • Los strings tienen largo maximo definido.
  • Los IDs se validan como UUID (no strings arbitrarios).
  • Las fechas se validan como formato valido y rango razonable.
  • No hay inyeccion SQL: se usan parametros preparados (TypeORM/Prisma lo hacen por default).
  • No hay inyeccion de comandos: no se ejecutan comandos del sistema con input del usuario.

4. Datos Sensibles

  • Los passwords nunca se retornan en responses de API.
  • Los tokens (JWT, refresh) no se loggean.
  • Los datos de salud (diagnosticos, recetas) se manejan con cuidado extra.
  • Los datos personales (email, telefono) no se exponen en endpoints publicos o de busqueda.
  • La BD tiene encriptacion at-rest habilitada.
  • Las conexiones a BD usan SSL/TLS.
  • Los archivos .env y credenciales NO estan en el repositorio.

5. Headers de Seguridad

  • Strict-Transport-Security (HSTS): fuerza HTTPS.
  • X-Content-Type-Options: nosniff: previene MIME type sniffing.
  • X-Frame-Options: DENY: previene clickjacking.
  • Content-Security-Policy: restringe origenes de scripts/estilos.
  • X-XSS-Protection: 0: (deshabilitado, CSP lo reemplaza).
  • CORS configurado con origenes especificos (no * en produccion).

6. API Security

  • Rate limiting global configurado.
  • Paginacion en todos los endpoints que retornan listas (evitar data dump).
  • Los error responses no incluyen stack traces en produccion.
  • Los error responses usan codigos especificos (no mensajes internos del framework).
  • Request body size limitado (ej: 1MB max).
  • File uploads validados: tipo MIME, tamano, extension.

7. Dependencias

  • npm audit no reporta vulnerabilidades high/critical.
  • Las dependencias estan fijadas a versiones especificas (lockfile).
  • No hay dependencias abandonadas (sin updates en 2+ anos) para funcionalidad critica.

8. Logging y Monitoreo de Seguridad

  • Los intentos de login fallidos se loggean (con IP, sin password).
  • Los accesos denegados (403) se loggean.
  • Los cambios de password/email se loggean como eventos de seguridad.
  • Hay alertas para patrones sospechosos (muchos 403, muchos login fallidos).

Ejemplo: Checklist aplicado a la Feature de Bookings

Check Estado Nota
Endpoints requieren JWT OK Guard global + excepciones explicitas
Paciente solo ve sus bookings OK Filtro por patientId del JWT en query
Medico solo ve su agenda OK Filtro por doctorId en query
Input validation en POST /bookings OK class-validator en CreateBookingDto
Rate limiting en reserva OK 5 req/min por paciente
No leak de datos de paciente en busqueda OK Busqueda de medicos no expone pacientes
Concurrencia protegida OK SELECT FOR UPDATE en transaccion
Logs de booking creado/cancelado OK Info level con bookingId, patientId
Error responses genericos PENDIENTE Algunos errores exponen nombres de columnas

Checklist de Completitud

  • Secciones de autenticacion, autorizacion, input validation cubiertas
  • Datos sensibles, headers, API security cubiertas
  • Dependencias y logging cubiertos
  • Ejemplo concreto aplicado
  • Revisada por otro ingeniero

Archivos relacionados