OWASP Top 10, explicado para quien dirige un negocio
Los diez riesgos de seguridad más comunes en aplicaciones web, sin jerga: qué son, qué pueden costarte y qué preguntar a tu proveedor.
OWASP es una fundación abierta que lleva más de veinte años documentando cómo se rompen las aplicaciones web. Su lista más conocida, el OWASP Top 10, recoge las diez categorías de vulnerabilidades más frecuentes y peligrosas. No es una norma legal, pero en la práctica funciona como el estándar mínimo que cualquier web o aplicación seria debería superar.
Si diriges un negocio, no necesitas memorizar la lista. Necesitas entender qué significa cada riesgo en dinero y reputación, y qué preguntarle a quien te construye o mantiene el software.
Los riesgos que más vemos en pymes
Control de acceso roto: la vulnerabilidad número uno. Significa que un usuario puede ver o tocar cosas que no le corresponden — por ejemplo, cambiar el número de un pedido en la URL y ver el pedido de otro cliente. Es la más común y una de las más graves.
Fallos criptográficos: contraseñas guardadas sin cifrar, webs sin HTTPS, datos sensibles viajando en claro. Si tu web pide datos y no los protege, el problema legal (RGPD) es tuyo, no solo del proveedor.
Inyección: el clásico. Un formulario mal protegido permite colar instrucciones a la base de datos. Un atacante puede leer, modificar o borrar información. Se previene con prácticas de desarrollo que hoy son básicas — si tu proveedor no las aplica, es una señal de alarma.
Componentes vulnerables y desactualizados: la mayoría del software moderno se construye sobre librerías de terceros. Si nadie las actualiza, heredas sus agujeros. Por eso el mantenimiento no es un extra: es parte de la seguridad.
Qué preguntar a tu proveedor
¿Revisáis el código contra el OWASP Top 10 antes de publicar? ¿Qué cabeceras de seguridad configura mi web? ¿Cada cuánto se actualizan las dependencias? ¿Hay copias de seguridad y se ha probado restaurarlas? Quien trabaja bien responde a estas preguntas sin ponerse nervioso.
En ReXyo auditamos contra OWASP tanto el código que escribimos como el que genera la IA — porque el código generado también hereda estos riesgos, y publicarlo sin revisar es jugártela.