Cuando se publicaron las Políticas de Seguridad de Contenido (CSP), el alcance inicial estaba diseñado para mitigar el Cross-Site Scripting (XSS) y las inyecciones maliciosas en el lado del cliente a través de recursos cargados desde el cliente. Con el tiempo, CSP fue evolucionando y hoy cuenta con un total de 31 directivas con distintos niveles de soporte entre navegadores y 3 formatos de reporte diferentes.
Estas cabeceras permiten al propietario de un sitio web definir qué fuentes son de confianza para cargar JavaScript, fuentes tipográficas, hojas de estilo o iFrames. También permiten definir conexiones externas para la exfiltración de datos. Una CSP correctamente implementada puede prevenir comportamientos no deseados. Sin embargo, CSP no es especialmente amigable para el usuario y tiene algunos fallos importantes; puedes leer más al respecto aquí.
Dicho esto, ¿debería una extensión del navegador poder eliminar estas cabeceras de forma silenciosa?
La lógica de la especificación
"La política aplicada a un recurso no debería interferir con el funcionamiento de características del agente de usuario como complementos, extensiones o bookmarklets. Este tipo de funcionalidades generalmente priorizan las preferencias del usuario sobre las del autor de la página, tal como se defiende en [HTML-DESIGN]."
En términos simples: tu navegador es tu cliente. Tu cliente tiene prioridad sobre la seguridad de la página web que visitas. Esto tiene lógica. Si no fuera así, es probable que los navegadores lo hicieran de todas formas. Los navegadores pueden decidir no seguir las especificaciones tal como están definidas, y eso ocurre en el mundo actual. Una especificación del W3C suele verse como un objetivo final alcanzado mediante compromisos a lo largo del camino.
Sin embargo…
¿No ve todo el mundo el problema aquí?
Mi preocupación:
"De acuerdo, W3C, pero mi abuelo no sabría que al instalar una extensión está permitiendo que esta elimine funciones de seguridad esenciales de los sitios web."
El problema va más lejos. Muchos navegadores actualizan las extensiones de forma activa sin requerir aprobación explícita ni confirmación del usuario. Esto significa que una extensión puede comportarse de manera completamente diferente de un día para otro, sin que el usuario sea notificado.
Lamentablemente, a lo largo de mi carrera he notado que las personas no suelen pensar en sus padres o abuelos cuando desarrollan tecnología. Ya sea por un descuido inconsciente o por otra razón, algún día seremos mayores y nuestros hijos podrían hacer lo mismo con nosotros. ¿Por qué somos así?
Los navegadores son máquinas de funcionalidades. La seguridad es una funcionalidad más. Si surgen preocupaciones de seguridad serias, eventualmente se hará algo al respecto gracias a la presión externa y la indignación pública. Pero la prioridad sigue siendo las funcionalidades llamativas, y la seguridad simplemente no se trata como prioridad número 1.
¿Cuál sería la solución?
Esto va más allá del ámbito del W3C, pero debería formar parte del marco de seguridad más amplio de los navegadores, fomentando una actitud autorregulada y consciente de la seguridad por parte de las empresas que desarrollan navegadores.
Me pregunto: ¿por qué no convertir esto en una opción de activación explícita?
Si una extensión, en el momento de instalación o actualización, añade la funcionalidad de eliminar o modificar cabeceras de seguridad, debería informar al usuario y requerir su aprobación.
La seguridad en el lado del cliente es un espacio de problemas fascinante; el tema anterior es solo uno de los muchos aspectos que están fundamentalmente mal implementados y que resultan peligrosos. Aunque planteo esto como un problema a nivel del W3C, en realidad se trata de un fallo de seguridad de diseño propio de los navegadores.
Hay mucho más. Protege a tus clientes, prueba cside.
