Notas
Auditoría de seguridad, botón de actualización de clientes y el 502 que explicó
Una auditoría con gancho bloqueador destapa fallos silenciosos; nace el botón
4 min de lectura
Hay días en los que programas cosas nuevas. Y hay días en los que dedicas a mirar de cerca lo que ya habías programado, con una linterna. El 1 de octubre me tocó lo segundo: una auditoría de seguridad completa del proyecto, un botón nuevo que actualiza webs de clientes solas, y un error 502 que me enseñó cómo funciona por dentro la puerta de entrada de un servidor.
La inspección: encontrar los agujeros antes que otros
Una auditoría de seguridad es como la inspección técnica de un edificio: vas sistema por sistema buscando grietas antes de que alguien las aproveche. En este caso, la revisión la hizo un agente de IA con un gancho especial (Mimosa) que directamente bloquea cualquier commit —cualquier entrega de código al repositorio— si detecta problemas serios sin resolver.
Y encontró cosas. La más llamativa: la analítica de la web —el sistema que cuenta visitas— llevaba rota desde hacia tiempo, fallando en cada visita, y nadie se había dado cuenta. Un fallo de esos es silencioso porque lo que falla es el contador, no la web. También estaban las claves de la IA demasiado a la vista desde el panel: el equivalente a dejar el código de la alarma pegado en la puerta.
Arreglarlo bien, no solo apagar el aviso
Lo importante de una auditoría no es la lista de problemas, es cerrarlos con garantías. Así que cada arreglo trajo lo suyo:
- Validar lo que nos llega de fuera: cuando la IA descarga una imagen o analiza la web de la competencia, ahora se comprueba que la dirección es pública y legítima en cada salto. Sin esto, una dirección maliciosa puede hacer que el servidor hable con sus propios servicios internos (un ataque llamado SSRF, que es básicamente colar a alguien de dentro a la zona privada).
- Feeds a prueba de bombas: los feeds RSS externos se parsean ahora con una librería que desactiva las trampas típicas del formato XML (lo que se conoce como ataques XXE).
- Tests automáticos en cada cambio: la integración continua —la CI, el robot que revisa el código cada vez que lo tocas— ahora también prueba la API, no solo construye imágenes.
- Claves enmascaradas: el panel ya no muestra las claves reales; las esconde detrás de una máscara, como una contraseña con asteriscos.
Todo verificado con 18 tests nuevos. Y al final, la prueba de fuego: una release nueva aplicada desde el botón del panel en la web de cliente real, y la analítica respondiendo con un 204 —el código HTTP que dice "recibido y correcto"— en producción.
El botón que actualiza webs de clientes
Aquí venía una asimetría molesta: el núcleo del producto se actualiza con un botón desde el panel, pero la web pública de cada cliente se actualizaba a mano, por SSH. El trabajo del día la cerró: ya existe el botón "Actualizar web pública".
Por dentro hace una cadena elegante: pregunta a GitHub cuál es la imagen exacta de la última versión (un digest, su huella digital), la descarga, la levanta y, si algo falla, deshace. Sin entrar en ningún servidor a mano. Doce tests nuevos protegen todo el flujo.
El 502: el portero con la lista antigua
Y el susto del día. Tras aplicar una actualización, el panel devolvía un 502 —el código de "puerta mala"—. Los contenedores estaban vivos y respondían por dentro, pero de fuera no se llegaba.
La causa es de manual: la puerta de entrada del servidor (el gateway, un Nginx) mantiene una lista de "a qué dirección interna va cada servicio". Y resulta que esa lista solo la consulta al arrancar. La actualización había recreado los contenedores con direcciones nuevas, pero el portero seguía apuntando a las viejas. Como llamar a un teléfono que cambió de número.
El arreglo tiene dos capas: configurar el Nginx para que vuelva a preguntar las direcciones cada 10 segundos (usando el DNS interno de Docker), y que el actualizador reinicie el gateway tras cada actualización del núcleo, para cubrir las instalaciones que aún tienen la configuración vieja.
Lo que se lleva uno
El día resumió el ciclo completo que me gusta en este proyecto: auditar, arreglar con tests, publicar firmado y verificar en producción con un cliente real. En la entrada anterior del diario se presentaba la documentación pública del producto; este es el día en que lo escarbamos por dentro. Y la entrada siguiente trae el primer rollback real y una migración con misterio incluido.