El Top 10 de OWASP aparece en presentaciones, pliegos de licitación y listas de requisitos de clientes, y mucha gente lo conoce de nombre sin haberlo leído. Es un documento de una organización abierta que reúne las categorías de riesgo más frecuentes en aplicaciones web. Sirve para que un equipo hable el mismo idioma, no para certificar nada.
Cómo conviene leerlo
Es una guía de concienciación. Cada entrada agrupa muchas fallas concretas bajo un nombre general, y la lista se actualiza cada tanto con datos aportados por la comunidad. Si tu aplicación esquiva las diez categorías, eso no demuestra que sea segura: hay problemas que no figuran porque son específicos de tu negocio. Tomalo como un piso común, no como una checklist completa.
Voy a repasar las categorías de la edición más reciente sin numerarlas, porque el orden cambia y lo que importa es el hábito que previene cada una.
Fallas de acceso y de criptografía
Control de acceso roto. El usuario hace algo que no le corresponde, como ver el recurso de otro. El hábito: verificar permisos en el servidor, en cada petición, sobre cada objeto.
Fallas criptográficas. Datos sensibles sin cifrar, algoritmos viejos, claves mal manejadas. El hábito: usar bibliotecas estándar, cifrar en tránsito y en reposo lo que sea sensible, y no inventar esquemas propios.
Fallas de identificación y autenticación. Contraseñas débiles, sesiones que no expiran, recuperación de cuentas insegura. El hábito: delegar lo posible a componentes probados y revisar los flujos de login con ojo malicioso.
Fallas de registro y monitoreo. Si no queda rastro de lo que pasa, un ataque puede durar meses sin que nadie lo vea. El hábito: registrar intentos de login, cambios de permisos y errores de autorización, sin guardar datos secretos en los registros, y que alguien los mire.
Fallas de diseño y de configuración
Inyección. Datos del usuario que terminan interpretados como código en una consulta o un comando. El hábito: separar siempre datos de instrucciones, con consultas parametrizadas y APIs que no pasen por un intérprete.
Diseño inseguro. Un problema que no se arregla con un parche porque está en el planteo. Por ejemplo, un flujo de compra que confía en el precio enviado desde el navegador. El hábito: pensar en abusos al diseñar, preguntándote qué haría alguien que quiera aprovecharse de esta función.
Configuración de seguridad incorrecta. Cuentas por defecto, mensajes de error con detalles internos, almacenamiento público por descuido. El hábito: configuraciones reproducibles y revisadas, con lo mínimo habilitado.
Componentes vulnerables y desactualizados. Tu código puede ser impecable y la biblioteca que usás, no. El hábito: saber qué dependencias tenés, actualizarlas con regularidad y usar herramientas que avisen de problemas conocidos.
Integridad, cadena de suministro y servidores
Fallas de integridad de software y datos. Aceptar actualizaciones, paquetes o datos serializados sin verificar su origen. El hábito: validar firmas o sumas de verificación, y no deserializar contenido no confiable con mecanismos que ejecuten código.
Falsificación de peticiones del lado del servidor. Una función que hace pedidos a una dirección que le pasa el usuario, y que termina alcanzando servicios internos. El hábito: listas de destinos permitidos y no confiar en direcciones recibidas.
Según la edición, algunas categorías se fusionan, se renombran o cambian de lugar. Lo que se mantiene es la idea de fondo.
Cómo usarlo en el equipo
Una lista larga que nadie toca no previene nada. Algunas formas de volverla útil:
- Elegí una categoría por sprint o por mes y dediquen media hora a mirar dónde podría aparecer en su propio código.
- Llevala a la revisión de código. Para un cambio que toca autenticación, preguntá explícitamente por control de acceso y por registro.
- Usala para priorizar las pruebas. Si tenés una API, empezá por las categorías que más aplican a APIs.
- Sumala a la definición de terminado en las tareas sensibles, con una o dos preguntas concretas.
- Revisá la lista cuando salga una edición nueva, para ver qué cambió y por qué.
Un truco que funciona: cuando aparece un bug de seguridad, clasificarlo con alguna de estas categorías y anotar qué hábito faltó. Con el tiempo se ve el patrón de tu equipo, que seguramente no coincide con el de un promedio general, y ahí está lo que más te conviene reforzar.