Seguridad de aplicaciones web: lo básico que casi nadie hace
La seguridad rara vez falla por falta de tecnología disponible. Falla por decisiones pequeñas tomadas con prisa: un endpoint sin verificación del dueño del recurso, un campo aceptado sin validación, una clave subida en un archivo de configuración. El objetivo de este artículo es describir el conjunto mínimo de prácticas que, aplicado con disciplina, elimina la mayor parte de los incidentes que aparecen en la práctica.
Autenticación responde quién; autorización responde qué
Confundir ambos conceptos es el origen de toda una clase de fallos. Autenticar significa establecer con confianza la identidad de quien llama. Autorizar significa decidir, para cada recurso concreto, si esa identidad puede leer o modificar ese dato específico.
En la práctica, el fallo más común es autorizar por ruta y no por registro: el sistema verifica que el usuario esté logueado, pero no verifica si el pedido le pertenece. Esa verificación debe ocurrir en el servidor, lo más cerca posible del dato — en reglas de base de datos cuando la plataforma ofrece ese recurso.
- Toda consulta sensible filtra por el identificador del usuario autenticado, nunca por un parámetro que venga del cliente.
- Los roles quedan en una tabla propia, jamás en un campo editable del perfil.
- Las reglas de acceso se prueban como cualquier otra regla de negocio.
La entrada es hostil por definición
Toda información que viene de fuera —formulario, query string, cabecera, webhook, archivo enviado— debe tratarse como potencialmente maliciosa hasta ser validada contra un esquema explícito. Validar significa aceptar solo lo previsto, no intentar eliminar lo peligroso.
La recomendación vale igual para la salida: los datos renderizados en la interfaz deben tratarse según el contexto donde aparecen, y las consultas a la base de datos deben usar siempre parámetros, nunca concatenación de texto.
Secretos, dependencias y superficie expuesta
Las claves de API y credenciales pertenecen al entorno del servidor, con rotación prevista y acceso restringido. Si una clave puede leerse desde el navegador, debe considerarse pública y tener permisos compatibles con eso.
Las dependencias merecen el mismo cuidado: inventario conocido, actualización periódica y verificación automática de vulnerabilidades en el pipeline. Buena parte de las brechas explotadas en producción está en bibliotecas desactualizadas, no en código propio.
- Cabeceras de seguridad configuradas: política de contenido, aislamiento de origen y transporte seguro obligatorio.
- Límite de solicitudes por identidad y por origen para contener el abuso automatizado.
- Registro de eventos sensibles con fecha, origen y resultado, preservado para auditoría.
La respuesta a incidentes forma parte del sistema
Ninguna defensa es perfecta, así que el proyecto necesita prever el mal día: cómo revocar sesiones, cómo rotar claves, cómo identificar el alcance de una filtración y cómo comunicar a los afectados. Una organización que ensayó ese guion reduce un incidente a una molestia; una que nunca lo pensó convierte el mismo evento en crisis.
En resumen
La seguridad sostenible es rutina, no heroísmo: validar la entrada, autorizar por recurso, proteger los secretos, actualizar dependencias y ensayar la respuesta al incidente.
Casos de uso
Portal con datos de múltiples clientes
Aislamiento por organización aplicado en la base de datos, de forma que una consulta mal escrita en la aplicación no filtre datos entre cuentas.
API pública con integraciones de socios
Claves por socio, alcances mínimos, límite de uso y firma verificada en cada webhook recibido.
Área administrativa
Segundo factor obligatorio, sesiones cortas, pista de auditoría y bloqueo tras intentos inválidos.
Errores comunes
- Confiar solo en la validación hecha en el navegador.
- Guardar el rol de administrador en un campo que el propio usuario puede modificar.
- Exponer mensajes de error con detalle interno de base de datos o stack trace.
- Tratar la seguridad como etapa final, hecha después de la entrega.
Buenas prácticas
- Mínimo privilegio en todas las capas: base de datos, API, integraciones y personas.
- Validación por esquema en el borde, con tipos explícitos.
- Secretos fuera del repositorio, con rotación documentada.
- Pruebas automatizadas para reglas de acceso, no solo para reglas de negocio.
Libros recomendados
The Web Application Hacker's Handbook — Dafydd Stuttard e Marcus Pinto
Muestra cómo se ataca realmente a las aplicaciones, lo que cambia la forma de diseñar defensas.
Threat Modeling — Adam Shostack
Método estructurado para anticipar el riesgo antes de escribir código.
Security Engineering — Ross Anderson
Base conceptual sólida sobre por qué los sistemas seguros fallan en la práctica.
Preguntas frecuentes
- ¿Cuál es la diferencia entre autenticación y autorización?
- La autenticación establece quién es el usuario. La autorización decide qué puede hacer ese usuario con cada recurso específico.
- ¿Necesito segundo factor en todo sistema?
- En áreas administrativas y en cualquier acceso a datos sensibles, sí. Es la medida con mejor relación entre esfuerzo y reducción de riesgo.
- ¿La validación en el front-end no es suficiente?
- No. Mejora la experiencia, pero puede evitarse. La validación que protege el sistema es la del servidor.
- ¿Cómo saber si mis dependencias son vulnerables?
- Con verificación automática en el pipeline y revisión periódica de versiones, licencias y mantenimiento activo de los paquetes.
- ¿Cuánto cuesta hacer seguridad desde el principio?
- Mucho menos que corregirla después. El retrabajo de autorización y modelado es una de las reformas más caras en software.