Seguridad en software a medida: las vulnerabilidades que la mayoría ignora y cómo evitarlas

Cuando alguien piensa en seguridad de software, piensa en hackers sofisticados, ataques de día cero y titulares de filtraciones masivas. La realidad, en la inmensa mayoría de los casos que auditamos, es mucho menos cinematográfica: contraseñas guardadas sin cifrar, un endpoint que devuelve los datos de cualquier usuario si cambias un número en la URL, o un formulario que ejecuta cualquier cosa que le escribas en el campo equivocado. No son fallos exóticos. Son errores básicos que nadie revisó, en sistemas que funcionan perfectamente bien hasta el día en que alguien los prueba con mala intención.

Por qué el software a medida no es automáticamente más seguro

Existe la idea de que un software propio, hecho a medida para tu negocio, es intrínsecamente más seguro que una herramienta genérica porque 'nadie lo conoce'. Es al revés: la seguridad por oscuridad no protege nada, y un sistema a medida sin criterio de seguridad desde el diseño suele ser más vulnerable que un SaaS establecido, precisamente porque ese SaaS ya pasó por años de ataques reales y correcciones. La ventaja del software a medida no es la oscuridad, es que puedes exigir y verificar buenas prácticas desde el primer día, algo que con una caja negra de terceros no puedes hacer.

Las vulnerabilidades que más vemos, en orden de frecuencia

No son las más sofisticadas las que más daño hacen. Son las más comunes, porque aparecen una y otra vez en proyectos que se apresuraron para llegar a producción.

1. Inyección SQL: el clásico que nunca muere

Cuando un formulario o un parámetro de la URL se concatena directo dentro de una consulta a la base de datos, cualquiera que sepa qué escribir puede leer, modificar o borrar información que no debería tocar, sin necesitar contraseña ni permisos. Es uno de los ataques más antiguos que existen y sigue apareciendo en 2026 porque alguien, en algún punto, decidió que construir la consulta a mano era más rápido que usar consultas parametrizadas. La corrección es simple y no cuesta tiempo extra si se hace desde el inicio: nunca insertar directamente lo que escribe un usuario dentro de una consulta, siempre a través de parámetros que la base de datos trata como datos, nunca como código.

2. Control de acceso roto: ver lo que no te toca

Este es, en la práctica, el que más veces encontramos. Un usuario autenticado cambia el número de un pedido, de una factura o de un perfil en la URL, y el sistema le muestra los datos de otra persona sin verificar si tiene permiso para verlos. El sistema confirmó quién eres, pero nunca confirmó qué puedes ver. Es un error silencioso porque no rompe nada visible: el sistema sigue funcionando perfectamente, solo que le está entregando a cualquiera información que no le corresponde. La solución no es complicada técnicamente, es una disciplina: cada endpoint que devuelve datos de un recurso específico debe verificar, en el servidor y no solo en la interfaz, que el usuario autenticado tiene permiso sobre ese recurso exacto.

3. Datos sensibles guardados como si no lo fueran

Contraseñas en texto plano, números de tarjeta guardados sin necesidad, tokens de API escritos directo en el código fuente que después termina en un repositorio público. Cuando alguien finalmente accede a la base de datos —por la vulnerabilidad anterior, por un empleado descuidado o por una filtración de otro proveedor— la pregunta que decide si es un incidente menor o una crisis es si esos datos estaban cifrados o no. Las contraseñas nunca deberían poder leerse, ni siquiera por el equipo que construyó el sistema: se guardan con funciones de hash diseñadas para eso, no cifradas de forma reversible y mucho menos en texto plano.

4. Confiar en lo que llega del navegador

El precio de un producto, el rol de un usuario, el límite de una promoción: si esos valores se validan solo en el frontend y el backend los acepta tal cual llegan, cualquiera con las herramientas de desarrollador de su navegador puede modificarlos antes de enviarlos. El frontend existe para la experiencia del usuario legítimo, no para la seguridad del sistema. Toda validación que de verdad importa —precio, permisos, límites, propiedad de un recurso— tiene que repetirse en el servidor, porque el servidor es lo único que el atacante no controla.

5. Dependencias desactualizadas con vulnerabilidades conocidas

Ningún proyecto moderno se construye desde cero: se apoya en decenas o cientos de librerías de terceros. Cuando esas librerías tienen una vulnerabilidad reportada públicamente y nadie actualiza el proyecto, el sistema queda expuesto a un ataque que ya está documentado, con instrucciones, en internet. No hace falta que alguien te ataque específicamente a ti: existen escáneres automatizados que recorren internet buscando sistemas con versiones vulnerables conocidas. Mantener las dependencias actualizadas y revisar alertas de seguridad no es un lujo de equipos grandes, es mantenimiento básico que cuesta minutos y evita el tipo de incidente más evitable de todos.

6. Mensajes de error que dicen demasiado

Un error que muestra el stack trace completo, el nombre de la tabla de la base de datos o la versión exacta del framework no es solo poco profesional: es información gratis para quien está buscando cómo entrar. Cada detalle técnico expuesto en un mensaje de error es una pista menos que un atacante tiene que adivinar. En producción, el usuario debería ver un mensaje genérico y útil; el detalle técnico completo debe ir a un log interno que solo el equipo de desarrollo puede consultar.

Cómo evitarlas desde el diseño, no después del incidente

Ninguna de estas seis vulnerabilidades es difícil de evitar técnicamente. Lo difícil es acordarse de hacerlo cuando el equipo está bajo presión de entregar rápido. Por eso la seguridad no puede ser una revisión que se hace al final, sino un criterio que se aplica desde la primera línea de código.

• Validar y sanear todo input del usuario, siempre en el servidor, nunca confiando solo en lo que valida el frontend.
• Usar consultas parametrizadas o un ORM correctamente configurado, nunca concatenar texto directo en una consulta SQL.
• Verificar permisos por recurso en cada endpoint, no solo autenticación general: que el usuario esté logueado no significa que pueda ver cualquier dato.
• Cifrar contraseñas con funciones de hash diseñadas para eso, y cifrar en tránsito y en reposo cualquier dato sensible.
• Mantener un proceso de actualización de dependencias, con alertas automáticas cuando aparece una vulnerabilidad conocida en una librería que usas.
• Hacer una revisión de seguridad —interna o externa— antes de lanzar a producción cualquier sistema que maneje datos de clientes o pagos, no después de un incidente.

El costo de aplicar estas prácticas desde el diseño es prácticamente cero comparado con el costo de corregirlas después: un incidente de seguridad no solo cuesta el tiempo de arreglarlo, cuesta la confianza de los clientes que confiaron sus datos a un sistema que no estuvo a la altura. La seguridad no es una funcionalidad que se agrega al final, es un criterio que se aplica en cada decisión de diseño, desde la primera consulta a la base de datos hasta el último endpoint que se publica.