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.
Artículos relacionados
Preguntas frecuentes
Las dudas más comunes. Si la tuya no está, pregúntanos
En Tangram no queremos que la información pase por una cadena interminable de intermediarios donde se pierden los detalles importantes.
Contarás con un interlocutor que coordinará la comunicación y trasladará las decisiones al equipo responsable de tu proyecto.
Cuando sea necesario profundizar en cuestiones de estrategia, diseño o tecnología, podremos involucrar a los especialistas correspondientes.
Así tendrás una comunicación organizada, sin necesidad de gestionar personalmente a todos los profesionales que intervienen.
Queremos que tengas acceso al conocimiento de un equipo especializado, sin sufrir la complejidad de coordinarlo.
No tendrás que averiguar a quién escribir cada vez que tengas una duda.
En Tangram contemplamos la figura del Account Manager como interlocutor principal, encargado de acompañarte durante el proyecto, coordinar la comunicación y facilitar el seguimiento de las decisiones.
Nuestra metodología incluye reuniones de revisión, canales de comunicación y herramientas para que puedas participar en el trabajo.
La organización concreta, la frecuencia de las reuniones y los canales disponibles se establecerán según el proyecto contratado.
Lo importante es que sepas con quién hablar, en qué punto está tu proyecto y qué decisiones necesitan tu participación.
Sí, podemos valorar una colaboración con los profesionales que ya trabajan en tu empresa.
No siempre tiene sentido sustituir un equipo que conoce bien tu negocio. En muchas situaciones, lo más útil es complementar sus conocimientos con especialistas en determinadas áreas.
Podemos estudiar qué responsabilidades asumiría Tangram, cuáles mantendría tu equipo y cómo coordinar las decisiones para evitar duplicidades.
La forma concreta de colaboración dependerá de la organización, las herramientas y las necesidades del proyecto.
No se trata de reemplazar lo que ya funciona, sino de aportar el conocimiento que necesitas para llegar más lejos.
No tienes por qué cambiar de proveedor para explorar una colaboración con Tangram.
Durante nuestra trayectoria hemos trabajado con agencias y consultoras, participando en proyectos en los que cada empresa asumía una parte diferente del trabajo.
Esa experiencia nos permite comprender la importancia de definir responsabilidades y coordinar a los profesionales implicados.
Podemos valorar una colaboración para cubrir necesidades concretas que tu proveedor actual no ofrece o para reforzar determinadas áreas.
Si tienes una relación profesional que funciona, no queremos que la rompas sin motivo. Queremos encontrar dónde podemos aportar valor.
La confidencialidad es especialmente importante cuando hablamos de nuevas ideas de negocio, información económica, estrategias comerciales o desarrollos tecnológicos.
En Tangram tenemos experiencia trabajando en proyectos sujetos a acuerdos de confidencialidad, motivo por el que no podemos mostrar públicamente muchos de los trabajos en los que hemos participado.
Si tu proyecto requiere un acuerdo de confidencialidad (NDA) antes de compartir información sensible, podemos revisar sus condiciones y acordar cómo proteger esa información antes de entrar en los detalles.
Entendemos que la confianza empieza por respetar lo que todavía no quieres hacer público.