wwt3_encryption para TYPO3

Por qué la ofuscación de correo sigue siendo obligatoria en cualquier sitio público

Cualquier web corporativa, cualquier página universitaria y cualquier sede electrónica publica direcciones de correo: personas de contacto en el aviso legal, interlocutores en equipos, contactos de prensa en salas de prensa, asesoría jurídica en las notas de protección de datos. Sin protección, los bots harvester recolectan esas direcciones en pocos días tras su publicación y las venden a remitentes de spam. wwt3_encryption es una extensión clásica de TYPO3 para este problema y cifra las direcciones de correo en el servidor, de modo que los bots solo ven código inutilizable al parsear el HTML, mientras que los usuarios reales pueden hacer clic en la dirección correcta. La extensión se dirige a operadores que por obligación legal deben mostrar los datos de contacto de forma prominente, pero no están dispuestos a asumir la avalancha de spam resultante.

Escenarios típicos de uso

Un despacho de abogados con 60 socios y asociados publica todos los perfiles de letrados incluyendo direcciones de correo directas, porque el Estatuto General de la Abogacía exige un dato de contacto accesible. Sin ofuscación, las 60 direcciones reciben en cuestión de semanas correos de phishing, publicidad y, en parte, ataques dirigidos. wwt3_encryption renderiza las direcciones de modo que el código fuente no contiene una cadena @ legible, mientras que el navegador del usuario muestra la dirección correcta del enlace mailto.

Un segundo escenario es una universidad que mantiene páginas de departamento con contactos de cátedras. Cada cátedra tiene una página web con datos de teléfono y correo que se mantienen editorialmente a través del gestor de contenido TYPO3. Los redactores introducen las direcciones como texto normal en elementos RichText o campos de contacto, sin tener que preocuparse por la ofuscación. wwt3_encryption interviene automáticamente en el proceso de renderizado y protege todos los enlaces mailto sin trabajo editorial adicional.

El tercer caso son administraciones públicas con aviso legal, formularios de contacto y listas de áreas funcionales. Aquí el requisito es a menudo aún más estricto, porque existe una exigencia de accesibilidad: la dirección protegida debe ser leída correctamente por lectores de pantalla, y un clic debe abrir el cliente de correo, igual que con una dirección no ofuscada. Una combinación de decodificación JavaScript y atributos href semánticamente limpios es el único camino para cumplir ambas cosas.

Arquitectura técnica: content post-processing en el renderizado TYPO3

wwt3_encryption se engancha al proceso de renderizado de TYPO3, típicamente mediante un hook de content post-processor o un userFunc de TypoScript. Tras el ensamblado del HTML por el Page Renderer, la extensión recorre el markup terminado, encuentra todos los enlaces mailto y todas las direcciones de correo simples en el texto corrido mediante regex y las sustituye por variantes ofuscadas. La ofuscación puede funcionar con distintos métodos: codificación ROT13 del destino del enlace con decodificación JavaScript, codificación Base64, fragmentación carácter a carácter con pseudoelementos CSS o una combinación.

La ventaja de la variante post-processing es que funciona sin cambios en los elementos de contenido o las plantillas. Los redactores siguen trabajando con enlaces mailto normales en el RichText y la extensión se encarga del blindaje automáticamente. La extensión se configura mediante constantes TypoScript, que permiten elegir entre los distintos métodos de ofuscación y definir excepciones para determinadas páginas o áreas de contenido.

Problemas frecuentes y soluciones

El primer problema es la accesibilidad. Las soluciones puramente JavaScript fallan con usuarios que tienen JavaScript desactivado, y algunos lectores de pantalla tienen problemas con la fragmentación de caracteres basada en CSS. Un enfoque pragmático combina una ofuscación ligera del lado del cliente con un aria-label semántico adicional en el enlace, de modo que los lectores de pantalla leen la dirección correctamente, mientras que los harvester fracasan ante la diferencia sintáctica. Con direcciones accesibles públicamente no se alcanza una seguridad absoluta, pero incluso barreras moderadas reducen medible la carga de spam.

El segundo problema son las capas de caché. Cuando la ofuscación por post-processing se ejecuta antes del Page Cache, el caché entrega los datos ya ofuscados y todo funciona. Si en cambio está después del caché, cada página cacheada se vuelve a pasar por el post-processor con cada petición, lo que reduce claramente el rendimiento. Por tanto el orden correcto en la cadena de renderizado TypoScript es crítico y debería revisarse en cada cambio importante en el comportamiento de caché.

El tercer tema afecta a los contenidos dinámicos. Las direcciones de correo que se cargan vía AJAX o que provienen de APIs externas no pasan por el renderer de TYPO3 y, por tanto, tampoco por wwt3_encryption. Esos puntos deben protegerse por separado, o bien haciendo que la propia API entregue variantes ofuscadas, o bien con un JavaScript del lado del cliente que post-procese el contenido recargado.

Migración y compatibilidad de versiones

wwt3_encryption tiene, como muchas extensiones antiguas de TYPO3, una historia de versiones desigual: para v9 y v10 había releases mantenidos, para v11 y v12 existen forks comunitarios con actividad variable. Quien migra a TYPO3 v13 debería comprobar antes del upgrade si su fork sigue funcionando o si se hace necesario cambiar a un método alternativo de ofuscación.

El núcleo de TYPO3 trae de serie una ofuscación sencilla de correo que se activa mediante config.spamProtectEmailAddresses en TypoScript y aplica ROT13 en el renderer del núcleo. Para instalaciones sencillas basta esa variante del núcleo y hace innecesaria una extensión propia. Quien necesita una ofuscación más fuerte o más flexible, por ejemplo con varios métodos en paralelo o excepciones por elemento de contenido, recurre a una extensión como wwt3_encryption. Gosign evalúa en cada caso si la función del núcleo es suficiente o si una extensión dedicada tiene sentido, y apoya cuando hace falta la reconstrucción hacia una implementación post-processing propia y ligera que se adapta al proyecto concreto.

La eficacia de cualquier ofuscación de correo disminuye con el tiempo, porque las técnicas harvester evolucionan. ROT13 se considera hoy prácticamente ineficaz frente a bots especializados, mientras que la fragmentación carácter a carácter con CSS o trucos Unicode todavía levanta barreras moderadas. La defensa realmente sólida es por tanto una combinación: ofuscación en la salida HTML, complementada con un buen filtro de spam en el lado del destinatario e, idealmente, una opción de contacto mediante formulario en lugar de una dirección directamente publicada. Quien debe cumplir los requisitos legales no podrá evitar la publicación, pero debería ofrecer el formulario de contacto como vía principal y mostrar la dirección solo de forma secundaria.

Para operadores de TYPO3 v13 se recomienda además revisar periódicamente el pipeline de renderizado de contenido frente a Breaking Changes del núcleo. Algunos puntos de hook que estaban disponibles en versiones anteriores para post-processing han sido declarados deprecated en v13 o sustituidos por eventos PSR-14. Las extensiones que se apoyan todavía en hooks antiguos siguen funcionando técnicamente tras el upgrade, pero ya no procesan contenidos. Una breve revisión de los logs tras un upgrade muestra esos fallos silenciosos a tiempo y evita que durante semanas se entreguen direcciones sin ofuscar sin que nadie lo note.