Seguridad en aplicaciones web modernas

La seguridad no es opcional. Cada día surgen nuevas vulnerabilidades y técnicas de ataque. Esta guía completa cubre las mejores prácticas y herramientas para proteger tus aplicaciones web en 2024.

OWASP Top 10: Las vulnerabilidades críticas

1. Broken Access Control

La vulnerabilidad #1 según OWASP 2021:

• Usuarios acceden a recursos sin autorización
• Escalada de privilegios
• IDOR (Insecure Direct Object References)
• Modificación de URLs para acceder a otros datos

Prevención:

• Denegar por defecto, excepto recursos públicos
• Implementar control de acceso centralizado
• Validar ownership en cada operación
• Deshabilitar directory listing
• Rate limiting en APIs
• Invalidar JWT tokens en logout

2. Cryptographic Failures

Fallas en protección de datos sensibles:

• Transmisión de datos en texto plano
• Algoritmos criptográficos débiles o deprecados
• Claves de encriptación por defecto o débiles
• No usar HTTPS correctamente

Mejores prácticas:

• HTTPS everywhere con TLS 1.3
• Usar algoritmos modernos: AES-256-GCM, ChaCha20-Poly1305
• Bcrypt o Argon2 para passwords (nunca MD5 o SHA1)
• Secrets en variables de entorno o vaults
• HSTS header para forzar HTTPS
• Perfect Forward Secrecy (PFS)

3. Injection

SQL, NoSQL, OS command injection:

• Input malicioso interpretado como código
• SQL injection sigue siendo prevalente
• Command injection en shells
• LDAP, XPath injection

Defensa:

• Prepared statements y parameterized queries SIEMPRE
• ORMs configurados correctamente
• Validación de input whitelist (no blacklist)
• Escapar caracteres especiales
• Least privilege en database users
• WAF para detección de patrones maliciosos

4. Insecure Design

Fallas fundamentales en arquitectura:

• No aplicar threat modeling
• Falta de security requirements
• No validar business logic

Solución:

• Shift left security - diseñar con seguridad desde inicio
• Threat modeling (STRIDE, PASTA)
• Security stories en cada sprint
• Revisión de arquitectura por security team

5. Security Misconfiguration

Configuraciones inseguras por defecto:

• Puertos innecesarios abiertos
• Mensajes de error verbosos en producción
• Features no usados habilitados
• Credenciales por defecto
• CORS mal configurado

Hardening:

• Deshabilitar features no necesarios
• Remover cuentas y passwords por defecto
• Security headers: CSP, X-Frame-Options, X-Content-Type-Options
• Automated security scanning en CI/CD
• Principle of least privilege

Autenticación y autorización modernas

JSON Web Tokens (JWT) - Buenas prácticas

• Usar algoritmo RS256 o ES256 (no HS256 con secrets débiles)
• Tokens cortos: 5-15 minutos para access tokens
• Refresh tokens con rotación
• Almacenar en httpOnly, secure, SameSite cookies
• Nunca en localStorage (vulnerable a XSS)
• Validar iss, aud, exp claims
• Implementar token revocation list si es crítico

OAuth 2.0 y OpenID Connect

• OAuth 2.0 para autorización (no autenticación directa)
• OpenID Connect (OIDC) para autenticación
• Authorization Code Flow con PKCE
• Nunca usar Implicit Flow (deprecado)
• State parameter para prevenir CSRF

Multi-Factor Authentication (MFA)

Esencial para seguridad moderna:

• TOTP (Time-based One-Time Password) con apps como Authy, Google Authenticator
• WebAuthn para biometría y security keys
• SMS como último recurso (vulnerable a SIM swapping)
• Recovery codes encriptados

Passwordless authentication

• Magic links por email
• WebAuthn/FIDO2 con passkeys
• Biometría en dispositivos
• Reduce ataque de phishing

Protección contra XSS (Cross-Site Scripting)

Tipos de XSS

• Stored XSS: Script malicioso almacenado en BD
• Reflected XSS: Script en URL reflejado en respuesta
• DOM-based XSS: Manipulación del DOM client-side

Defensa multi-capa

• Input validation: Sanitizar todo input de usuario
• Output encoding: HTML entity encoding en templates
• CSP (Content Security Policy): Header restrictivo
• DOMPurify: Librería para sanitizar HTML
• Frameworks modernos: React, Vue, Angular escapan por defecto
• Cuidado con dangerouslySetInnerHTML: Usar solo con sanitización

Content Security Policy ejemplo

• default-src 'self'
• script-src 'self' 'nonce-{random}'
• style-src 'self' 'unsafe-inline' (idealmente eliminar unsafe-inline)
• img-src 'self' data: https:
• connect-src 'self' https://api.tuapp.com
• frame-ancestors 'none'

Protección CSRF (Cross-Site Request Forgery)

Cómo funciona CSRF

Atacante engaña al navegador para enviar requests autenticados:

• Usuario autenticado en sitio legítimo
• Visita sitio malicioso
• Sitio malicioso envía request al sitio legítimo
• Navegador incluye cookies automáticamente

Prevención

• CSRF Tokens: Token único por sesión/request
• SameSite cookies: SameSite=Strict o Lax
• Double Submit Cookie: Token en cookie y header
• Custom headers: X-Requested-With en AJAX
• Origin/Referer checking: Validar origen de request
• GET requests nunca deben modificar estado

HTTPS y TLS configuración

Certificados SSL/TLS

• Let's Encrypt para certificados gratuitos
• Renovación automática con certbot
• Wildcard certificates para subdominios
• Certificate pinning en mobile apps

Configuración TLS óptima

• TLS 1.3 únicamente (deshabilitar 1.0, 1.1, 1.2 si es posible)
• Cipher suites seguros: ECDHE+AESGCM, ChaCha20-Poly1305
• Perfect Forward Secrecy (PFS)
• HSTS con includeSubDomains y preload
• OCSP stapling para mejor performance

Security headers esenciales

• Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
• X-Frame-Options: DENY (prevenir clickjacking)
• X-Content-Type-Options: nosniff
• Referrer-Policy: strict-origin-when-cross-origin
• Permissions-Policy: Controlar features del navegador

Dependencias y supply chain security

El problema

• Proyectos modernos tienen cientos de dependencias
• Dependencias transitivas multiplicadas
• Vulnerabilidades descubiertas constantemente
• Ataques a npm packages (typosquatting, compromised packages)

Herramientas de scanning

• npm audit / yarn audit: Built-in scanning
• Snyk: Continuous monitoring, fix PRs automáticos
• Dependabot (GitHub): PRs automáticos para updates
• OWASP Dependency-Check: Open source scanner
• Socket.dev: Detecta malware en packages

Mejores prácticas

• Mantener dependencias actualizadas
• Revisar package-lock.json en code reviews
• Usar package.json con versiones específicas o ~
• Evitar ^ que puede traer breaking changes
• Auditar nuevas dependencias antes de agregar
• Considerar bundle size y seguridad al elegir libs
• Usar subresource integrity (SRI) para CDNs

API Security

Rate limiting y throttling

• Prevenir DoS y brute force attacks
• Por IP, por usuario, por API key
• Token bucket o leaky bucket algorithms
• Headers: X-RateLimit-Limit, X-RateLimit-Remaining
• 429 Too Many Requests con Retry-After

API Keys y secrets

• Nunca en código fuente o repositorios
• Variables de entorno
• Secrets managers: AWS Secrets Manager, Azure Key Vault, HashiCorp Vault
• Rotación regular de keys
• Scope mínimo necesario

Input validation

• Validar en backend SIEMPRE (no confiar en frontend)
• Schema validation: Joi, Yup, Zod
• Type checking en APIs (TypeScript, GraphQL)
• Reject unknown fields
• Validate data types, formats, ranges

API versioning y deprecation

• Versioning en URL: /api/v1/users
• Deprecation warnings en responses
• Sunset header para anunciar fin de soporte
• Mantener versiones antiguas temporalmente

Seguridad en contenedores

Docker security

• Usar imágenes oficiales y verificadas
• Imágenes distroless para mínima superficie de ataque
• Multi-stage builds para imágenes pequeñas
• No correr como root: USER directive
• Escanear vulnerabilidades: Trivy, Clair, Snyk
• Read-only filesystems cuando sea posible
• .dockerignore para no incluir secrets

Kubernetes security

• RBAC estricto (Role-Based Access Control)
• Network policies para segmentar tráfico
• Pod Security Standards/Admission
• Secrets en etcd encriptados
• Service mesh (Istio, Linkerd) para mTLS
• Falco para runtime threat detection

Logging y monitoring de seguridad

Qué loggear

• Authentication attempts (exitosos y fallidos)
• Authorization failures
• Input validation failures
• API abuse (rate limiting triggers)
• Cambios en permisos/roles
• Administrative actions

Qué NO loggear

• Passwords
• Tokens o API keys
• Tarjetas de crédito completas
• PII sensible sin enmascarar

SIEM y alerting

• SIEM: Splunk, Elastic Security, Sumo Logic
• Alertas en tiempo real para eventos críticos
• Correlación de eventos
• Dashboards de seguridad

Testing de seguridad

SAST (Static Application Security Testing)

• Análisis de código fuente
• Herramientas: SonarQube, Checkmarx, Semgrep
• Integrar en IDE y CI/CD
• Falsos positivos requieren tuning

DAST (Dynamic Application Security Testing)

• Testing de aplicación en runtime
• Black box testing
• Herramientas: OWASP ZAP, Burp Suite, Acunetix
• Automated scanning en staging

Penetration testing

• Manual testing por expertos
• Al menos anualmente
• Después de cambios arquitectónicos mayores
• Bug bounty programs para continuous testing

Compliance y regulaciones

GDPR (Europa)

• Derecho al olvido
• Data portability
• Privacy by design
• Breach notification en 72 horas

PCI DSS (Payment Card Industry)

• Requerido si procesas tarjetas de crédito
• Mejor usar Stripe/PayPal para evitar PCI scope
• Nunca almacenar CVV
• Tokenización de tarjetas

Security checklist para lanzamiento

Pre-deployment

• HTTPS configurado correctamente
• Security headers implementados
• Secrets en vaults, no en código
• Dependencies actualizadas, sin vulnerabilidades críticas
• SAST y DAST ejecutados
• Penetration testing completado
• Rate limiting en APIs
• Logging y monitoring configurados
• Backup y disaster recovery plan

Post-deployment

• Monitoring activo de logs
• Alertas configuradas
• Incident response plan documentado
• Continuous security scanning
• Regular security updates

Conclusión

La seguridad es un proceso continuo, no un estado. Las amenazas evolucionan constantemente y requieren vigilancia permanente.

Implementar todas estas medidas puede parecer abrumador, pero la clave está en priorizar: comenzar con lo fundamental (HTTPS, autenticación robusta, input validation) y construir sobre esa base.

En Trixasoft, la seguridad es prioritaria desde el diseño. Cada feature incluye security considerations, ejecutamos testing automatizado en cada commit, y mantenemos un programa de actualizaciones continuas. La seguridad no es solo responsabilidad del security team - es de todo el equipo de desarrollo.