Seguridad en aplicaciones web a medida: protección de datos y RGPD

Llevo doce años entrando a comités de dirección a explicar lo mismo: cuando encargas una aplicación web a medida, te quedas con el control, sí, pero también con toda la responsabilidad. La parte que en un SaaS asume el proveedor —el cumplimiento técnico, el parcheo, la respuesta a incidentes— ahora cae sobre tu organización. Y los CEOs que me escuchan suelen tardar dos reuniones en entenderlo, hasta que les enseño el listado público de sanciones de la AEPD.

Por eso este artículo va sobre seguridad en aplicaciones web a medida, protección de datos y RGPD desde el punto de vista de quien firma el plan de continuidad, no de quien programa el endpoint. Voy a separar lo que el reglamento exige sobre el papel de lo que realmente reduce el riesgo cuando alguien intenta entrar a las tres de la mañana. No son lo mismo, aunque a veces se confundan.

Un dato para situarnos: en 2025 la AEPD acumuló más de 50 millones de euros en sanciones, y la tendencia sigue al alza. Air Europa pagó 600.000 euros por la brecha de 2018, Vodafone España acumula cerca de 5 millones en multas distintas, y media docena de pymes han recibido sanciones de entre 30.000 y 200.000 euros por cosas tan prosaicas como un formulario de contacto sin base jurídica clara. Si tu app gestiona datos personales, esto te afecta.

Lo que el RGPD exige por diseño (y dónde la gente lo interpreta mal)

El artículo 25 obliga a integrar protección de datos desde el diseño y por defecto. Suena bien en una diapositiva. En código quiere decir que cuando un desarrollador junior añade un campo "fecha de nacimiento" al formulario de registro porque "queda más completo", está creando exposición innecesaria. Minimización significa preguntar, en cada campo nuevo, qué finalidad legítima lo justifica. Si no hay respuesta clara, fuera.

Hay cuatro decisiones de arquitectura que conviene tomar al inicio y no a los seis meses:

• Minimización real de datos. No es un postit pegado al monitor, es una revisión periódica del modelo de datos. Cada tres meses imprimo el esquema y tachamos columnas.
• Control de acceso por roles. Cada endpoint, cada consulta y cada panel administrativo segmentado. El admin de marketing no debe poder leer facturación.
• Cifrado en tránsito y en reposo. TLS 1.3 en todo, AES-256 para los datos sensibles en base de datos. Esto ya es estándar y la AEPD lo da por supuesto.
• Pseudonimización donde tenga sentido. Separar identificadores de comportamiento. Si me roban la tabla de eventos, que no se lleven nombres y emails.

El principio de mínimo privilegio, explicado al CEO

Cuando le digo a un director general que "aplicamos mínimo privilegio", suele asentir sin entender. Lo traduzco así: ningún usuario, servicio o componente puede acceder a más datos de los que necesita para hacer su trabajo. El servicio que envía emails de marketing no debería poder leer la tabla de pagos. La conexión a base de datos del frontend público no debería tener permisos de escritura sobre la tabla de auditoría. Cuando esto se hace bien, una credencial robada compromete una esquina, no la casa entera.

Vulnerabilidades que sigo encontrando en auditorías

El OWASP Top 10 lleva años marcando el patrón. Pero el problema no es que los desarrolladores no lo conozcan, es que las prisas y los presupuestos ajustados hacen que se asuman atajos. Estas son las cuatro que más veces firmo en mis informes.

Inyección SQL y de comandos

Se previene con consultas parametrizadas y ORMs que abstraigan el acceso a datos. Lo sé yo, lo sabe el desarrollador. Aun así, el mes pasado encontré una consulta dinámica construida con concatenación de strings en un panel interno que llevaba dos años en producción. Nadie lo había revisado porque "es interno". Lo interno también se ataca, sobre todo desde dentro.

Cross-Site Scripting (XSS)

React y Vue escapan variables por defecto, así que el XSS clásico ha bajado. Pero sigue apareciendo cuando alguien usa dangerouslySetInnerHTML o renderiza HTML guardado en base de datos sin sanitizar. Content Security Policy bien configurado es la red de seguridad que te salva cuando el código falla.

Autenticación frágil

Lo que veo más a menudo: contraseñas con hash MD5 en bases de datos heredadas, tokens de sesión con entropía pobre, ausencia de rate limiting en el endpoint de login. La receta básica no es negociable:

• Contraseñas con bcrypt, scrypt o Argon2, salt único por usuario.
• MFA obligatorio para roles administrativos. No opcional, obligatorio.
• Tokens de sesión con entropía suficiente y caducidad razonable.
• Rate limiting y bloqueo temporal tras intentos fallidos.
• Recuperación de contraseña con tokens de un solo uso y expiración corta.

Control de acceso roto (broken access control)

Es la vulnerabilidad número uno del OWASP Top 10 y la que más sanciones está generando. Un usuario cambia un ID en la URL y accede a la factura del de al lado. Una petición a un endpoint de API sin validar permisos en el servidor. La regla es simple: la autorización se verifica en servidor, siempre, incluso cuando el frontend ya ha ocultado el botón.

Cumplimiento del RGPD: las piezas que la AEPD revisa primero

Registro de actividades de tratamiento

Cuando la AEPD llama a tu puerta, lo primero que pide es el registro de actividades. Finalidades, categorías de datos, destinatarios, plazos de conservación, medidas de seguridad. Si no lo tienes actualizado, la inspección empieza ya con mal pie. Mantenerlo es trabajo de DPO, pero la app debe facilitarle los datos.

Base jurídica de cada tratamiento

Cada dato que recoges necesita una base válida: consentimiento, ejecución de contrato, obligación legal, interés legítimo, intereses vitales o misión pública. La sanción a una clínica madrileña de 2024 por 70.000 euros fue precisamente por tratar datos de salud sin base jurídica documentada. El consentimiento, cuando se usa, tiene que ser libre, específico, informado e inequívoco, y revocarse con el mismo clic con el que se otorgó.

Derechos de los interesados (ARCO-POL)

Implementar estos derechos como funcionalidades del producto es más barato que gestionarlos a mano por correo:

• Acceso: el usuario consulta qué datos suyos almacenas.
• Rectificación: corrige datos inexactos sin tener que llamarte.
• Supresión (derecho al olvido): borra sus datos cuando ya no son necesarios.
• Portabilidad: descarga sus datos en formato estructurado y legible por máquina.
• Oposición y limitación: rechaza tratamientos concretos o limita el uso.

Un panel de privacidad en el perfil del usuario resuelve el 90% de las solicitudes sin intervención humana.

Notificación de brechas en 72 horas

El plazo del artículo 33 es de 72 horas desde que detectas la brecha, no desde que la entiendes del todo. Para cumplirlo necesitas monitorización activa, un protocolo de respuesta ensayado (no improvisado el día que pasa), capacidad para evaluar el alcance en horas, y logs que permitan reconstruir lo ocurrido. Sin estos cuatro elementos, las 72 horas se te echan encima.

Evaluación de impacto (EIPD)

Tratamiento masivo de datos sensibles, perfilado automatizado con efectos jurídicos, videovigilancia sistemática. Si tu app cae en alguno de estos supuestos, la EIPD es obligatoria antes de empezar el tratamiento. La AEPD publica una lista orientativa que conviene revisar antes del kickoff técnico.

Arquitectura: lo que realmente protege cuando alguien intenta entrar

Perímetro

• WAF (Cloudflare, AWS WAF, ModSecurity) filtrando tráfico malicioso antes de tocar la aplicación.
• CDN con protección DDoS absorbiendo ataques volumétricos.
• TLS 1.2 o superior en todo el tráfico, con HSTS configurado para impedir downgrade.

Capa de aplicación

• Headers de seguridad completos: Content-Security-Policy, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy.
• Tokens anti-CSRF en cada formulario o petición que modifique estado.
• Rate limiting por IP y por usuario, no solo en login sino en endpoints de API sensibles.

Capa de datos

• Cifrado en reposo para todo dato personal en base de datos.
• Backups cifrados y almacenados en ubicaciones separadas de los sistemas productivos.
• Retención automatizada que elimina datos cuando expira el plazo. Lo manual se olvida.

Testing de seguridad: qué se hace y cuándo

Un proceso serio de testing y QA de aplicaciones web a medida debe incluir capas específicas de seguridad:

• SAST (SonarQube, Semgrep) durante el desarrollo, integrado en el pipeline CI.
• DAST (OWASP ZAP, Burp Suite) sobre la aplicación en ejecución antes de cada release importante.
• Pentesting profesional antes de lanzar y al menos una vez al año en producción.
• Auditoría de dependencias (Snyk, npm audit) automatizada y bloqueante en CI.

El error frecuente es dejar todo esto para "cuando lancemos". Para entonces, rehacer arquitectura es diez veces más caro que haberla hecho bien.

Cuándo conviene auditar antes de que duela

Si tu aplicación lleva más de un año en producción y no ha pasado por un pentest serio, estás operando con incertidumbre. Si tienes datos personales sensibles —salud, datos financieros, menores— y no has hecho una EIPD, el riesgo regulatorio se acumula cada día. Y si la última revisión de roles y permisos fue cuando contrataste al primer desarrollador, hay puertas abiertas que ya nadie recuerda.

La seguridad en aplicaciones web a medida, protección de datos y RGPD no se resuelve con un PDF descargable. Se resuelve revisando código, arquitectura y procesos, y cerrando los huecos uno a uno. Si quieres una mirada externa, hagamos una auditoría rápida y te decimos en una semana qué encontramos y por dónde empezar.

Cuando la AEPD llama, ya es tarde para empezar.