Cuando hablamos de desarrollo web, la seguridad suele quedar en segundo plano hasta que ocurre un incidente. He visto equipos excelentes cometer los mismos errores una y otra vez. En este artículo voy a detallar los fallos más comunes que encontramos en auditorías y cómo solucionarlos antes de que sea tarde.
Si tu equipo quiere profundizar en estos temas, te recomiendo visitar nuestra guía sobre Secure Web Engineering. Y si necesitas ayuda con tu proyecto, podemos revisar tu código o arquitectura en nuestro servicio de desarrollo web.
Los 3 errores más críticos
1. Confiar ciegamente en la entrada del usuario
El error número uno es asumir que los datos que llegan del cliente son seguros. Esto incluye parámetros de URL, cuerpos de peticiones, cabeceras y archivos subidos. Un atacante puede manipular cualquier campo.
Solución: Validar y sanitizar siempre en el servidor. Usa listas blancas para valores permitidos y escapa la salida según el contexto (HTML, JSON, SQL). Implementa prepared statements para bases de datos.
2. Gestión insegura de sesiones y autenticación
Muchas aplicaciones almacenan tokens JWT en localStorage sin protegerlos contra XSS, o usan cookies sin las flags HttpOnly y Secure. También es común tener endpoints de login sin límite de intentos.
Solución: Usa cookies con SameSite=Strict, HttpOnly y Secure. Implementa rate limiting en login y usa refresh tokens rotados. Nunca almacenes secretos en el cliente.
3. Exposición de información sensible
Errores como mostrar stack traces en producción, incluir contraseñas en el código fuente (hardcoded) o devolver datos internos en respuestas API son más frecuentes de lo que crees.
Solución: Configura el manejo de errores para no filtrar detalles. Usa variables de entorno para secretos. Revisa las respuestas de tus endpoints para asegurarte de que solo devuelven lo necesario.
Checklist de verificación rápida (prueba concreta)
Usa esta lista en tu próxima revisión de código o antes de un despliegue:
- Todas las entradas de usuario se validan en el servidor (no solo en el cliente).
- Las consultas a base de datos usan parámetros preparados o un ORM seguro.
- Las contraseñas se almacenan con un algoritmo de hash fuerte (bcrypt, Argon2).
- Las cookies de sesión tienen HttpOnly, Secure y SameSite configurados.
- Los endpoints sensibles tienen límite de intentos y registro de accesos.
- No hay secretos (API keys, contraseñas) en el código fuente.
- Los mensajes de error no revelan detalles internos (stack traces, rutas).
- Las cabeceras de seguridad (CSP, HSTS, X-Frame-Options) están presentes.
- Las dependencias están actualizadas y se revisan vulnerabilidades conocidas.
- Se realizan pruebas de seguridad automatizadas (SAST, DAST) en el pipeline.
Este checklist forma parte de nuestro runbook de ingeniería segura. Si quieres una copia completa, contáctanos.
Preguntas frecuentes
¿Qué es el error más común en desarrollo web? El más común es no validar la entrada del usuario en el servidor. Muchos desarrolladores confían en la validación del frontend, pero un atacante puede saltársela fácilmente.
¿Cómo puedo empezar a mejorar la seguridad de mi aplicación web? Empieza por implementar las cabeceras de seguridad básicas (CSP, HSTS, X-Frame-Options) y asegurar la autenticación con cookies seguras y límite de intentos. Luego aplica el checklist anterior.
¿Debo usar JWT o sesiones tradicionales? Depende del caso. Las sesiones tradicionales con cookies HttpOnly son más seguras para aplicaciones web clásicas. JWT es útil para APIs, pero requiere cuidado con el almacenamiento del token y la rotación.