Guía de exorcismo digital: cómo migrar una web corporativa a código estático
Qué significa exorcizar una web corporativa: el criterio jurídico que decide qué se elimina, qué se conserva y qué resultado verificable produce. El cierre del archivo de El Cuervo.
Sunt mala quae libas, ipse venena bibas.
La Acusación
El mercado tiene una respuesta estándar para una web lenta, insegura o sancionable: rediseñarla. Cambiar la plantilla, actualizar el tema, migrar a un hosting "premium", instalar un plugin de caché que disimule la lentitud. El vocabulario varía —rediseño, optimización, modernización—, pero la operación de fondo es siempre la misma: sustituir una capa visible del problema sin tocar la arquitectura que lo genera.
Los seis expedientes anteriores de este archivo documentan, cada uno desde un ángulo distinto, la misma conclusión: el problema no está en cómo se configura un CMS dinámico para una web corporativa. Está en que ese CMS exista. El plugin vulnerable, la sanción por cookies, la cuota de mantenimiento sin techo, la transferencia internacional no declarada, el banner innecesario, el formulario que captura de más: ninguno de esos seis hallazgos se corrige con una versión más reciente del mismo sistema. Se corrigen eliminando el sistema.
Eso es lo que distingue un exorcismo de un rediseño. Un rediseño cambia la superficie y conserva la arquitectura. Un exorcismo audita la arquitectura completa y conserva solo lo que supera una prueba muy concreta.
El Cuerpo del Delito
El criterio: la misma prueba de necesidad, aplicada a todo el sistema
El Expediente VI de este archivo ancló la doctrina de la minimización de datos —artículo 5.1.c del RGPD— a los campos de un formulario: cada dato solicitado tiene que justificarse en la finalidad declarada, o desaparece. Esa misma prueba, aplicada no a un formulario sino a la totalidad del código que compone una web, es el criterio que gobierna un exorcismo digital.
Cada elemento de la web —cada plugin, cada script, cada conexión externa, cada campo de base de datos, cada dependencia de terceros— se somete a una sola pregunta: ¿esto es estrictamente necesario para que esta web cumpla su función declarada? No "¿es útil?". No "¿lo pidió alguien hace tres años?". No "¿lo tiene la competencia?". Estrictamente necesario, en el mismo sentido jurídico en que el artículo 5.1.c exige que un dato personal sea necesario para la finalidad que lo justifica.
La diferencia entre esta pregunta y un rediseño convencional es que la respuesta no la decide quien construye la web. La decide quien es titular de ella, con información completa sobre qué representa cada elemento en términos de riesgo, coste y exposición legal —el mismo principio que ya describía la home de este sitio: revisar cada componente, uno por uno, y decidir con el cliente, no por él.
Tres resultados posibles, no dos
Aplicar esa prueba no produce una lista binaria de "lo que se queda" y "lo que se va". Produce tres categorías.
Lo que no supera la prueba, desaparece. El mapa interactivo que nadie consulta, el slider de imágenes que ralentiza la carga sin aportar información, el sistema de comentarios de un blog que lleva tres años sin entrada nueva, el campo de teléfono en un formulario cuya función es recibir un correo de contacto. Cada uno de estos elementos es, simultáneamente, peso muerto funcional y superficie de exposición activa: cuanto más código y más conexiones externas, más vectores documentados en este archivo —vulnerabilidades de plugin, transferencias internacionales, captura desproporcionada de datos.
Lo que supera la prueba pero compromete privacidad, se sustituye. Una web corporativa necesita, casi siempre, mostrar una dirección, recibir consultas y, en ocasiones, reproducir contenido audiovisual. La función es legítima. El modo en que el mercado la resuelve por defecto —un iframe que llama a un servidor de terceros, un script que se ejecuta antes de cualquier consentimiento— no lo es. En estos casos, el ejercicio no es eliminar la función, sino encontrar o construir la forma de cumplirla sin generar la transferencia de datos que el Expediente IV documentó con sentencias firmes.
Lo que supera la prueba y no compromete nada, se traduce. El contenido real de la web —los textos, las imágenes, la identidad visual, la estructura de navegación que el visitante reconoce— no cambia. Se traslada, tal cual, a una forma de código que no depende de una base de datos para existir en cada visita.
Lo que significa traducir a código estático
La traducción no es una migración de plataforma en el sentido en que el mercado usa ese término —mover los mismos archivos de un proveedor a otro, conservando la misma arquitectura dinámica—. Es una reconstrucción completa: el HTML y el CSS que el navegador del visitante recibe se generan una sola vez, antes de la visita, no en cada petición.
La diferencia técnica tiene una consecuencia legal que ya recorre todo este archivo. Una web que no reconstruye nada en cada visita no necesita una base de datos que consultar —y sin base de datos, no hay vector de inyección que un plugin vulnerable pueda explotar. No ejecuta plugins de terceros en segundo plano —y sin esos plugins, no hay parche pendiente, ni intervalo de exposición, ni cuota mensual para gestionar un riesgo que ya no existe. No depende de un gestor de contenidos que decida, sin que el titular lo audite, qué scripts cargar y cuándo.
El proceso completo se valida en un entorno aislado, separado de la web en producción, antes de que ningún visitante real lo vea. La web actual permanece operativa durante todo el proceso. El cambio se produce en un único momento, después de la aprobación del titular, no como una migración progresiva que conviva con el sistema antiguo.
Un rediseño cambia lo que el visitante ve. Un exorcismo cambia lo que el código ejecuta cuando nadie está mirando. Solo el segundo elimina el riesgo de origen, porque el riesgo nunca estuvo en la superficie.
La Sentencia
El resultado de este proceso no es una versión más rápida o más bonita de la misma web. Es una web que no tiene nada que el resto de este archivo pueda investigar.
No hay plugin de cookies, porque no hay cookies de terceros que gestionar. No hay banner, porque no hay nada que requiera el consentimiento que el artículo 22.2 de la LSSI exige. No hay base de datos que un atacante pueda inyectar, ni intervalo entre una vulnerabilidad publicada y un parche pendiente, porque no hay plugins instalados que parchear. No hay petición a un servidor fuera del Espacio Económico Europeo, porque no hay ningún recurso externo cargándose en el navegador del visitante. No hay un formulario capturando más datos de los que la respuesta exige, porque cada campo superó la misma prueba que el resto del código.
Lo que queda es legible, auditable y propiedad exclusiva de quien lo encargó: sin dependencias ocultas, sin terceros con acceso silencioso, sin una cuota recurrente para mantener viva una arquitectura que, en una web de este perfil, nunca debió ser tan grande.
Quien haya seguido el archivo hasta este punto se habrá encontrado, en cada expediente, la misma cita latina abriendo el caso: sunt mala quae libas, ipse venena bibas — lo que me ofreces es veneno, bébetelo tú mismo. Esta es la única vez que este archivo explica de dónde viene.
La fórmula pertenece a la Medalla de San Benito, y resume una leyenda que el papa Gregorio Magno recogió en el Libro II de sus Diálogos, en el siglo VI. A Benito de Nursia, fundador del monacato occidental, un grupo de monjes intentó envenenarlo con una copa de vino; la copa se rompió al bendecirla. Más tarde, un sacerdote llamado Florencio, consumido por la envidia, le envió un pan envenenado. Benito, advertido del peligro, no lo probó: ordenó a un cuervo que solía alimentar que se lo llevara lejos, donde nadie pudiera alcanzarlo. El cuervo obedeció antes de que el veneno llegara a su destino.
Esa es la imagen que da nombre a este archivo. El Cuervo no bendice la copa ni neutraliza el veneno: lo detecta y lo aparta antes de que se consuma. Diagnostica. No exorciza. La fórmula completa de la medalla —Vade retro Satana, nunquam suade mihi vana; sunt mala quae libas, ipse venena bibas— es la advertencia que da nombre al protocolo de admisión de PRIBECY_: lo que una arquitectura insegura le ofrece a quien la mantiene no es protección. Es el mismo veneno, servido cada mes, con otro nombre.
El Cuervo es el archivo de diagnóstico de PRIBECY_