9 skills de seguridad que necesitas saber sí o sí en 2026

1. OWASP Top 10

OWASP publica cada pocos años la lista de los diez fallos de seguridad más habituales en aplicaciones web. No es un tratado: son diez cosas concretas, y llevan siendo casi las mismas quince años, lo que dice bastante de todos nosotros.

Leerla entera es una tarde y te ahorra la mayoría de los disgustos, porque los ataques de verdad casi nunca son sofisticados. No entran con una técnica nueva: entran por el control de acceso que nadie comprobó, por la librería que lleva tres años sin actualizar o por la configuración que se quedó como venía de fábrica.

2. Inyección: SQL, comandos y prompts

Toda inyección es el mismo error contado de formas distintas: mezclar datos que vienen de fuera con instrucciones que se van a ejecutar. Si pegas lo que escribe el usuario dentro de una consulta SQL, lo que escriba el usuario es SQL.

La solución lleva décadas resuelta y es siempre la misma: consultas parametrizadas. El dato viaja aparte y nunca se lee como instrucción. Y en 2026 hay una versión nueva del mismo problema: la inyección de prompt. Si metes texto de un usuario en las instrucciones de un modelo, ese texto son instrucciones. Mismo fallo, cincuenta años después.

3. Control de acceso roto e IDOR

Es el fallo número uno de la lista y también el más fácil de cometer. Ocultas el botón de «ver factura» a quien no debe verla, te quedas tranquilo, y resulta que la factura sigue estando en una URL con un número al final que cualquiera puede cambiar.

Eso es un IDOR: referencia directa a un objeto sin comprobar permisos. La regla es incómoda pero corta: cada petición comprueba si este usuario concreto puede hacer esto concreto sobre este dato concreto. En el servidor, siempre, aunque la interfaz ya lo impida. La interfaz no es una medida de seguridad.

4. Autenticación moderna

Las contraseñas se olvidan, se filtran y sobre todo se reutilizan: la misma que usa tu usuario en tu aplicación la usa en un foro que se filtró en 2019. Una passkey es una llave que vive en su móvil y se desbloquea con la huella o la cara. No hay nada que robar porque no hay nada que escribir.

Una vez dentro, el servidor entrega un token firmado que dice quién es y hasta cuándo vale. Con eso llama a tus APIs y ellas solo comprueban la firma. Dos detalles que se saltan casi todos: que el token dure poco y se renueve, y que no se guarde donde cualquier script de la página pueda leerlo.

5. Gestión de secretos

Las claves de API en el código son, con diferencia, la forma más tonta de que te entren. Y no vale con borrarlas en el siguiente commit: quedan para siempre en el historial de git, y hay robots recorriendo GitHub que las encuentran en cuestión de minutos.

Van en variables de entorno o, mejor, en un gestor de secretos que las rote solo. Y hay tres normas de propina: una clave distinta por entorno, un fichero de ejemplo con los nombres pero sin los valores, y un escáner de secretos en el pipeline para que la próxima no llegue a subirse.

6. Cifrado: en tránsito, en reposo y en uso

Un dato pasa por tres estados y cada uno se protege de una forma. En tránsito, mientras viaja por la red: eso es TLS, y hoy no tiene discusión, va en todo. En reposo, cuando está guardado en un disco: eso es cifrado de disco o de columna, y es lo que hace que un backup robado no sirva de nada.

El tercero es el que casi nadie considera: en uso, cuando el dato está descifrado en memoria para poder trabajar con él. Ahí es donde se lo lleva la mitad de las filtraciones y donde no hay bala de plata: se ataja teniendo el dato el menor tiempo posible, no registrándolo en los logs y no mandándolo a sitios donde no hace falta.

7. Cadena de suministro

Tu aplicación no es solo tu código. Instalas veinte dependencias, cada una trae las suyas, y acabas ejecutando en producción el trabajo de gente cuyo nombre no has leído nunca. Eso es la cadena de suministro, y es por donde han entrado los ataques más ruidosos de los últimos años.

No hay que dejar de usar librerías, hay que mirar el árbol. Fija las versiones, revisa qué se actualiza, ten un inventario de lo que ejecutas y pon algo automático que te avise cuando salga una vulnerabilidad. Y antes de instalar: mira cuándo se actualizó por última vez y cuánta gente la mantiene.

8. Zero Trust

El modelo antiguo era un castillo: un muro fuerte por fuera y confianza total por dentro. Funcionaba cuando todo estaba en una oficina. Hoy tienes servicios en tres nubes, gente trabajando desde su casa y proveedores conectados a tu red, así que el muro ya no rodea nada.

Zero Trust es la postura contraria: no te fíes de nadie por estar dentro. Cada petición se verifica, venga de un usuario, de un dispositivo o de otro servicio tuyo. Y cada uno recibe el permiso mínimo para su tarea, no el de toda la red. Suena paranoico hasta que alguien entra por un sitio y descubre que puede llegar a todos los demás.

9. Límites de uso y abuso

Hay ataques que no explotan ningún fallo: simplemente hacen lo permitido muchísimas veces. Probar contraseñas, pedir códigos por SMS que tú pagas, o gastarte el presupuesto de tu API de IA en una tarde. Si no hay límite, todo eso es gratis para quien lo hace.

Se defiende por capas y cada una tapa lo que la anterior deja pasar: límite por IP para lo tonto, por cuenta para el que rota IPs, retraso progresivo tras varios fallos y una verificación humana solo al final, cuando ya hay motivos. Y algo que avise cuando el gasto se dispare: lo peor de estos ataques es enterarte por la factura.

Resumen

• OWASP: quince años y casi la misma lista.
• Toda inyección es mezclar datos con instrucciones.
• Comprueba permisos en el servidor, no escondiendo el botón.
• Passkey para entrar, token corto para moverse.
• Ninguna clave en el repositorio, nunca.
• Cifra en tránsito, en reposo, y ten el dato poco tiempo en memoria.
• Mira el árbol de dependencias: son mil, no veinte.
• Zero Trust: estar dentro no es una credencial.
• Pon límites, o alguien hará lo permitido un millón de veces.

La seguridad no es un departamento que llega al final a decirte que no. Es una forma de escribir código, y casi toda cabe en una frase: no te fíes de nada que venga de fuera y comprueba siempre en el servidor. Si de las nueve solo te llevas una, que sea el control de acceso: es el número uno de la lista desde que existe la lista.