Lista de verificación de seguridad para revisiones de código de cambios en límites de confianza

Objetivo

Detectar los defectos de seguridad que una revisión general pasa por alto porque son código correcto que hace lo equivocado: una comprobación de autorización ausente, una salida sin escapar, una URL obtenida a partir de datos del usuario.

Requisitos previos

Una descripción del cambio que indique qué límites de confianza toca, una revisión general de diseño y corrección ya realizada, y los artículos enlazados de la wiki con los detalles de cada control. La OWASP Code Review Guide (citada) es la referencia extensa sobre esta misma actividad.

Pasos

1. Decide si la lista se aplica: ¿el cambio lee entradas de fuera del proceso, modifica quién puede hacer qué, toca una base de datos o el sistema de archivos, realiza peticiones salientes, maneja credenciales o claves, o añade una dependencia? Si no ocurre nada de esto, detente.
2. Entrada: para cada nuevo punto de entrada, localiza dónde se validan los datos (tipo, longitud, lista de permitidos) y dónde se usan; todo uso que construya una consulta, comando, ruta, URL o marcado debe pasar por parametrización o codificación, no por concatenación de cadenas.
3. Autenticación y sesiones: todo endpoint nuevo está protegido por la misma autenticación que los endpoints hermanos; el código de inicio de sesión, restablecimiento, MFA y tokens regenera identificadores y caducidades donde lo indiquen los artículos existentes.
4. Autorización: para cada objeto al que se accede mediante un identificador de la petición, localiza la comprobación de que el principal actual puede acceder a ese objeto, no solo al endpoint. Busca la comprobación ausente en la segunda ruta (masiva, exportación, administración, webhook).
5. Acceso a datos y almacenamiento: consultas parametrizadas; las columnas nuevas con datos personales están clasificadas y cubiertas por la política de retención; los archivos se escriben con un nombre aleatorio en una ubicación no ejecutable.
6. Peticiones salientes: toda URL construida a partir de una entrada pasa por la lista de permitidos contra SSRF; las redirecciones apuntan solo a rutas relativas o a hosts de la lista; XML, YAML y la serialización nativa se procesan con el cargador seguro.
7. Secretos y configuración: sin credenciales literales, sin secretos en registros ni en mensajes de error; la configuración nueva falla en modo cerrado cuando falta.
8. Dependencias: un paquete nuevo tiene una justificación, una versión fijada y un upstream mantenido; en un cambio del lockfile se revisa que no haya paquetes inesperados.
9. Registro y errores: las acciones relevantes para la seguridad generan un evento de auditoría; las respuestas de error no exponen stack traces ni hosts internos.
10. Redacta los hallazgos como preguntas con un enlace al artículo correspondiente; bloquea la fusión solo por los puntos de los pasos 2, 4 y 6, los que un atacante alcanza primero.

Resultado esperado

Los cambios que tocan límites de confianza reciben una segunda revisión coherente; los revisores dedican la atención de seguridad donde rinde y la omiten en el resto.

Límites y base de verificación

Es una propuesta, no una práctica medida. La lista encuentra omisiones, no fallos lógicos en las reglas de negocio, que requieren modelado de amenazas. Aplicarla a todos los cambios la diluye; aplicarla solo cuando el autor señala un límite de confianza depende de que el autor lo advierta.