Política de Seguridad del Contenido

Joe Medley
Jo Medley
Twitter GitHub

El modelo de seguridad de la Web se basa en la política de mismo origen. El código de https://mybank.com solo debería tener acceso a los datos de https://mybank.com, y nunca se le debería permitir el acceso a https://evil.example.com. Cada origen se mantiene aislado del resto de la Web, lo que brinda a los desarrolladores una zona de pruebas segura en la que pueden compilar y jugar. En teoría, esto es brillante. En la práctica, los atacantes han encontrado formas inteligentes de subvertir el sistema.

Los ataques de secuencias de comandos entre sitios (XSS), por ejemplo, omiten la misma política de origen cuando engañan a un sitio para que entregue código malicioso junto con el contenido previsto. Este es un gran problema, ya que los navegadores confían en todo el código que aparece en una página como parte legítima del origen de seguridad de esa página. La Hoja de referencia de XSS es una muestra antigua pero representativa de los métodos que un atacante podría usar para inyectar código malicioso y infringir esta confianza. Si un atacante inyecta cualquier código de forma correcta, habrá terminado: los datos de la sesión del usuario se comprometen y la información que debería mantenerse en secreto se robará a los chicos malos. Obviamente, queremos evitarlo si es posible.

En esta descripción general, se destaca una defensa que puede reducir de forma significativa el riesgo y el impacto de los ataques de XSS en navegadores modernos: la Política de Seguridad del Contenido (CSP).

Resumen

  • Usa listas de entidades permitidas para indicarle al cliente qué está permitido y qué no.
  • Obtén información sobre las directivas disponibles.
  • Conoce las palabras clave que usan.
  • El código intercalado y eval() se consideran perjudiciales.
  • Denuncia incumplimientos de política ante tu servidor antes de aplicarlos.

Lista de entidades permitidas de fuentes

El problema que aprovechan los ataques XSS es la incapacidad del navegador para distinguir entre una secuencia de comandos que forma parte de tu aplicación y una secuencia de comandos insertada de forma malintencionada por un tercero. Por ejemplo, el botón de +1 de Google en la parte inferior de esta página carga y ejecuta código de https://apis.google.com/js/plusone.js en el contexto del origen de esta página. Confiamos en ese código, pero no podemos esperar que el navegador descubra por sí solo que el código de apis.google.com es genial, mientras que el código de apis.evil.example.com probablemente no lo sea. El navegador descarga y ejecuta sin problemas cualquier código que solicite una página, sin importar la fuente.

En lugar de confiar ciegamente en todo que entrega un servidor, la CSP define el encabezado HTTP Content-Security-Policy, que te permite crear una lista de entidades permitidas de fuentes de contenido de confianza y le indica al navegador que solo ejecute o renderice recursos de esas fuentes. Incluso si un atacante puede encontrar un hueco a través del cual insertar una secuencia de comandos, esta no coincidirá con la lista de entidades permitidas y, por lo tanto, no se ejecutará.

Dado que confiamos en que apis.google.com entregará código válido y confiamos en que nosotros hacemos lo mismo, definamos una política que permita que se ejecute solo la secuencia de comandos cuando provenga de una de esas dos fuentes:

Content-Security-Policy: script-src 'self' https://apis.google.com

Parece simple, ¿verdad? Como probablemente adivinaste, script-src es una directiva que controla un conjunto de privilegios relacionados con la secuencia de comandos para una página específica. Especificamos 'self' como una fuente válida de secuencia de comandos y https://apis.google.com como otra. El navegador descarga y ejecuta JavaScript desde apis.google.com mediante HTTPS, además del origen de la página actual.

Error de la consola: Se negó a cargar la secuencia de comandos "http://evil.example.com/evil.js" porque infringe la siguiente directiva de la Política de Seguridad del Contenido: script-src 'self' https://apis.google.com

Cuando defines esta política, el navegador simplemente muestra un error en lugar de cargar la secuencia de comandos de cualquier otra fuente. Cuando un atacante inteligente logra insertar código en tu sitio, se encontrará con un mensaje de error en lugar del resultado exitoso que esperaban.

La política se aplica a una amplia variedad de recursos

Si bien los recursos de secuencias de comandos son los riesgos de seguridad más obvios, la CSP proporciona un amplio conjunto de directivas de políticas que permiten un control bastante detallado sobre los recursos que puede cargar una página. Ya viste script-src, por lo que el concepto debería estar claro.

Analicemos rápidamente el resto de las directivas de recursos. La siguiente lista representa el estado de las directivas a partir del nivel 2. Se publicó una especificación de nivel 3, pero no se implementó en gran medida en los navegadores principales.

  • base-uri restringe las URLs que pueden aparecer en el elemento <base> de una página.
  • child-src enumera las URLs para los trabajadores y el contenido de marcos incorporados. Por ejemplo: child-src https://youtube.com habilitaría la incorporación de videos de YouTube, pero no de otros orígenes.
  • connect-src limita los orígenes a los que puedes conectarte (a través de XHR, WebSockets y EventSource).
  • font-src especifica los orígenes que pueden entregar fuentes web. Las fuentes web de Google se pueden habilitar a través de font-src https://themes.googleusercontent.com.
  • form-action enumera los extremos válidos para el envío desde etiquetas <form>.
  • frame-ancestors especifica las fuentes que pueden incorporar la página actual. Esta directiva se aplica a las etiquetas <frame>, <iframe>, <embed> y <applet>. Esta directiva no se puede usar en las etiquetas <meta> y solo se aplica a los recursos que no son HTML.
  • frame-src dejó de estar disponible en el nivel 2, pero se restablece en el nivel 3. Si no está presente, igualmente se recurrirá a child-src como antes.
  • img-src define los orígenes desde los que se pueden cargar las imágenes.
  • media-src restringe los orígenes permitidos para enviar video y audio.
  • object-src permite controlar Flash y otros complementos.
  • plugin-types limita los tipos de complementos que puede invocar una página.
  • report-uri especifica una URL a la que un navegador enviará informes cuando se incumpla una política de seguridad del contenido. No se puede usar esta directiva en etiquetas <meta>.
  • style-src es el equivalente de script-src para las hojas de estilo.
  • upgrade-insecure-requests indica a los usuarios-agentes que reescriban los esquemas de URL y cambien de HTTP a HTTPS. Esta directiva es para sitios web con una gran cantidad de URL antiguas que se deben reescribir.
  • worker-src es una directiva de CSP de nivel 3 que restringe las URLs que se pueden cargar como trabajador, trabajador compartido o service worker. Desde julio de 2017, esta directiva tiene implementaciones limitadas.

De forma predeterminada, las directivas son muy abiertas. Si no estableces una política específica para una directiva, por ejemplo, font-src, esa directiva se comporta de forma predeterminada como si especificaras * como la fuente válida (por ejemplo, podrías cargar fuentes de cualquier lugar, sin restricciones).

Puedes anular este comportamiento predeterminado si especificas una directiva default-src. Esta directiva define los valores predeterminados para la mayoría de las directivas que dejas sin especificar. En general, esto se aplica a cualquier directiva que termine con -src. Si default-src está configurado como https://example.com y no especificas una directiva font-src, podrás cargar fuentes de https://example.com y de ninguna otra parte. En nuestros ejemplos anteriores, solo especificamos script-src, lo que significa que las imágenes, fuentes, etc., se pueden cargar desde cualquier origen.

Las siguientes directivas no usan default-src como resguardo. Recuerda que no establecerlas equivale a permitir todo.

  • base-uri
  • form-action
  • frame-ancestors
  • plugin-types
  • report-uri
  • sandbox

Puedes usar todas las directivas que consideres necesarias para tu aplicación específica. Solo debes enumerarlas en el encabezado HTTP y separar las directivas con punto y coma. Asegúrate de enumerar todos los recursos necesarios de un tipo específico en una única directiva. Si escribes algo como script-src https://host1.com; script-src https://host2.com, simplemente se ignorará la segunda directiva. Algo como lo siguiente especificaría correctamente que ambos orígenes son válidos:

script-src https://host1.com https://host2.com

Por ejemplo, si tienes una aplicación que carga todos sus recursos desde una red de distribución de contenidos (por ejemplo, https://cdn.example.net) y sabes que no necesitas complementos ni contenido con marcos, tu política podría ser similar a la siguiente:

Content-Security-Policy: default-src https://cdn.example.net; child-src 'none'; object-src 'none'

Detalles de la implementación

Verás los encabezados X-WebKit-CSP y X-Content-Security-Policy en varios instructivos en la Web. En el futuro, debes ignorar estos encabezados con prefijo. Los navegadores modernos (a excepción de IE) admiten el encabezado Content-Security-Policy sin prefijo. Ese es el encabezado que deberías usar.

Independientemente del encabezado que utilices, la política se define página por página: deberás enviar el encabezado HTTP junto con cada respuesta que quieras asegurarte de estar protegida. Esto proporciona mucha flexibilidad, ya que puedes ajustar la política para páginas específicas según sus necesidades específicas. Tal vez un conjunto de páginas de tu sitio tenga el botón de +1 y otras no. Puedes permitir que el código del botón se cargue solo cuando sea necesario.

La lista de fuentes de contenido en cada directiva es flexible. Puedes especificar las fuentes por esquema (data:, https:), o variar en especificidad desde solo el nombre de host (example.com, que coincide con cualquier origen en ese host: cualquier esquema y cualquier puerto) hasta un URI completamente calificado (https://example.com:443, que solo coincide con HTTPS, solo con example.com y solo con el puerto 443). Se aceptan comodines, pero solo como un esquema, un puerto o en la posición de más a la izquierda del nombre de host: *://*.example.com:* coincidiría con todos los subdominios de example.com (pero no en sí mismo example.com), mediante cualquier esquema, en cualquier puerto.

La lista de fuentes de contenido acepta cuatro palabras clave:

  • 'none', como es de esperarse, no coincide con nada.
  • 'self' coincide con el origen actual, pero no con sus subdominios.
  • 'unsafe-inline' permite JavaScript y CSS intercalados. (Más adelante trataremos esto con más detalle).
  • 'unsafe-eval' permite mecanismos de texto a JavaScript, como eval. (Ya hablaremos de esto también).

Estas palabras clave requieren comillas simples. Por ejemplo, script-src 'self' (con comillas) autoriza la ejecución de JavaScript desde el host actual; script-src self (sin comillas) permite JavaScript desde un servidor llamado "self" (y no desde el host actual), que probablemente no es lo que querías.

Zona de pruebas

Hay una directiva más que vale la pena mencionar: sandbox. Es un poco diferente de los otros que analizamos, ya que impone restricciones sobre las acciones que puede realizar la página en lugar de los recursos que puede cargar. Si está presente la directiva sandbox, se trata la página como si se cargara dentro de un <iframe> con un atributo sandbox. Esto puede tener una amplia variedad de efectos en la página, como forzarla a un origen único y evitar el envío de formularios, entre otros. Este artículo va un poco más allá del alcance de este artículo, pero puedes encontrar todos los detalles sobre los atributos válidos de la zona de pruebas en la sección "Zona de pruebas" de la especificación HTML5.

La metaetiqueta

El mecanismo de entrega preferido de la CSP es un encabezado HTTP. Sin embargo, puede ser útil establecer una política en una página directamente en el lenguaje de marcado. Para ello, usa una etiqueta <meta> con un atributo http-equiv:

<meta
  http-equiv="Content-Security-Policy"
  content="default-src https://cdn.example.net; child-src 'none'; object-src 'none'"
/>

No se puede usar para frame-ancestors, report-uri ni sandbox.

El código intercalado se considera perjudicial

Debería quedar claro que la CSP se basa en orígenes de lista de entidades permitidas, ya que es una forma no ambigua de indicarle al navegador que trate conjuntos específicos de recursos como aceptables y que rechace al resto. Sin embargo, las listas de entidades permitidas basadas en el origen no resuelven la mayor amenaza que representan los ataques de XSS: la inyección de secuencias de comandos intercaladas. Si un atacante puede insertar una etiqueta de secuencia de comandos que contiene directamente una carga útil maliciosa (<script>sendMyDataToEvilDotCom();</script>), el navegador no tiene un mecanismo para distinguirla de una etiqueta legítima de secuencia de comandos intercalada. La CSP resuelve este problema bloqueando por completo las secuencias de comandos intercaladas: es la única forma de asegurarse.

Este bloqueo incluye no solo secuencias de comandos incorporadas directamente en las etiquetas script, sino también controladores de eventos intercalados y URLs de javascript:. Deberás mover el contenido de las etiquetas script a un archivo externo y reemplazar las URLs de javascript: y <a ... onclick="[JAVASCRIPT]"> por las llamadas addEventListener() adecuadas. Por ejemplo, puedes reescribir lo siguiente:

<script>
  function doAmazingThings() {
    alert('YOU AM AMAZING!');
  }
</script>
<button onclick="doAmazingThings();">Am I amazing?</button>

a algo como esto:

<!-- amazing.html -->
<script src="amazing.js"></script>
<button id="amazing">Am I amazing?</button>

<div style="clear:both;"></div>

// amazing.js
function doAmazingThings() {
  alert('YOU AM AMAZING!');
}
document.addEventListener('DOMContentLoaded', function () {
  document.getElementById('amazing').addEventListener('click', doAmazingThings);
});

El código reescrito tiene varias ventajas más allá de que funciona bien con la CSP. Ya es una práctica recomendada, sin importar el uso de la CSP. JavaScript intercalado combina la estructura y el comportamiento exactamente de la manera deseada. Los recursos externos son más fáciles de almacenar en caché para los navegadores, más fáciles de comprender para los desarrolladores y propicios para la compilación y la reducción. Escribirás mejor código si te tomas el trabajo de mover el código a recursos externos.

El estilo intercalado se trata de la misma manera: tanto el atributo style como las etiquetas style deben consolidarse en hojas de estilo externas para protegerse de una variedad de métodos de robo de datos sorprendentemente inteligentes que permite CSS.

Si necesitas tener estilo y secuencia de comandos intercalados, puedes habilitarlos agregando 'unsafe-inline' como fuente permitida en una directiva script-src o style-src. También puedes usar un nonce o un hash (consulta a continuación), pero realmente no deberías hacerlo. Bloquear las secuencias de comandos intercaladas es la mayor victoria de seguridad que puede obtener la CSP, y prohibir el estilo intercalado también endurece la aplicación. Asegurarse de que todo funcione correctamente después de mover todo el código es un poco de esfuerzo al principio, pero ese es un problema que vale la pena hacer.

Si debes usarlo,

La CSP nivel 2 ofrece retrocompatibilidad para las secuencias de comandos intercaladas, ya que te permite agregar secuencias de comandos intercaladas específicas a la lista de entidades permitidas mediante un nonce criptográfico (número usado una vez) o un hash. Aunque esto puede resultar engorroso, es útil como sustituto.

Para usar un nonce, asigna un atributo nonce a tu etiqueta de secuencia de comandos. Su valor debe coincidir con uno de la lista de fuentes de confianza. Por ejemplo:

<script nonce="EDNnf03nceIOfn39fn3e9h3sdfa">
  // Some inline code I can't remove yet, but need to asap.
</script>

Ahora, agrega el nonce a tu directiva script-src junto a la palabra clave nonce-.

Content-Security-Policy: script-src 'nonce-EDNnf03nceIOfn39fn3e9h3sdfa'

Recuerda que los nonces deben volver a generarse para cada solicitud de página y deben ser indescifrables.

Los hashes funcionan de la misma manera. En lugar de agregar código a la etiqueta de la secuencia de comandos, crea un hash SHA de la secuencia de comandos y agrégalo a la directiva script-src. Por ejemplo, supongamos que tu página incluye lo siguiente:

<script>
  alert('Hello, world.');
</script>

Tu política contendría lo siguiente:

Content-Security-Policy: script-src 'sha256-qznLcsROx4GACP2dm0UCKCzCG-HiZ1guq6ZZDob_Tng='

Hay que tener en cuenta algunos aspectos. El prefijo sha*- especifica el algoritmo que genera el hash. En el ejemplo anterior, se usa sha256-. La CSP también es compatible con sha384- y sha512-. Cuando generes el hash, no incluyas las etiquetas <script>. Además, el uso de mayúsculas y los espacios en blanco son importantes, incluidos los espacios en blanco iniciales o finales.

Si realizas una Búsqueda de Google sobre cómo generar un hash SHA, verás soluciones en distintos idiomas. Con Chrome 40 o versiones posteriores, puedes abrir Herramientas para desarrolladores y volver a cargar tu página. La pestaña Console contendrá mensajes de error con el hash SHA256 correcto para cada una de tus secuencias de comandos intercaladas.

Evaluación también

Incluso cuando un atacante no pueda insertar una secuencia de comandos de forma directa, podría engañar a tu aplicación para que convierta texto inerte en JavaScript ejecutable y lo ejecute en su nombre. eval(), new Function(), setTimeout([string], ...) y setInterval([string], ...) son vectores a través de los cuales el texto inyectado podría terminar ejecutando algo malicioso de forma inesperada. La respuesta predeterminada de la CSP a este riesgo es bloquear por completo todos estos vectores.

Esto afecta de varias formas la manera en la que compilas las aplicaciones:

  • Debes analizar JSON a través del JSON.parse integrado, en lugar de depender de eval. Las operaciones nativas de JSON están disponibles en todos los navegadores desde IE8 y son completamente seguras.
  • Vuelve a escribir cualquier llamada a setTimeout o setInterval que estés haciendo actualmente con funciones intercaladas en lugar de strings. Por ejemplo:
setTimeout("document.querySelector('a').style.display = 'none';", 10);

se escribiría mejor de la siguiente manera:

setTimeout(function () {
  document.querySelector('a').style.display = 'none';
}, 10);
  • Evita las plantillas intercaladas en el entorno de ejecución: Muchas bibliotecas de plantillas usan new Function() libremente para acelerar la generación de plantillas en el tiempo de ejecución. Es una aplicación noventa de programación dinámica, pero existe el riesgo de evaluar texto malicioso. Algunos frameworks admiten CSP de inmediato, y recurren a un analizador sólido en ausencia de eval. La directiva ng-csp de AngularJS es un buen ejemplo de esto.

Sin embargo, una mejor opción sería un lenguaje de plantillas que ofrezca precompilación (Handlebars lo hace, por ejemplo). La compilación previa de tus plantillas puede hacer que la experiencia del usuario sea aún más rápida que la implementación del entorno de ejecución más rápida y, además, es más segura. Si eval y sus hermanos de texto a JavaScript son esenciales para tu aplicación, puedes habilitarlos agregando 'unsafe-eval' como fuente permitida en una directiva script-src, pero no lo recomendamos. Bloquear la capacidad de ejecutar cadenas hace que sea mucho más difícil para un atacante ejecutar código no autorizado en tu sitio.

Informes

La capacidad de la CSP para bloquear recursos que no son de confianza del cliente es una gran ventaja para tus usuarios, pero sería bastante útil que se envíe algún tipo de notificación al servidor para que puedas identificar y corregir, en primer lugar, cualquier error que permita la inserción maliciosa. Para ello, puedes indicarle al navegador que POST los informes de incumplimientos con formato JSON en una ubicación especificada en una directiva report-uri.

Content-Security-Policy: default-src 'self'; ...; report-uri /my_amazing_csp_report_parser;

Esos informes se verán más o menos de la siguiente manera:

{
  "csp-report": {
    "document-uri": "http://example.org/page.html",
    "referrer": "http://evil.example.com/",
    "blocked-uri": "http://evil.example.com/evil.js",
    "violated-directive": "script-src 'self' https://apis.google.com",
    "original-policy": "script-src 'self' https://apis.google.com; report-uri http://example.org/my_amazing_csp_report_parser"
  }
}

Encontrarás información útil que te ayudará a localizar la causa específica del incumplimiento, incluida la página en la que se produjo el incumplimiento (document-uri), la URL de referencia de esa página (a diferencia del campo de encabezado HTTP, la clave no está mal escrita), el recurso que infringió la política de la página (blocked-uri), la directiva específica que infringió (violated-directive) y la política completa de la página (original-policy).

Solo informes

Si recién comienzas a usar CSP, tiene sentido evaluar el estado actual de tu aplicación antes de implementar una política rigurosa para los usuarios. Como punto de partida para una implementación completa, puedes pedirle al navegador que supervise una política y que informe los incumplimientos, pero que no aplique las restricciones. En lugar de enviar un encabezado Content-Security-Policy, envía un encabezado Content-Security-Policy-Report-Only.

Content-Security-Policy-Report-Only: default-src 'self'; ...; report-uri /my_amazing_csp_report_parser;

La política especificada en el modo de solo informes no bloqueará los recursos restringidos, pero enviará informes de incumplimientos a la ubicación que especifiques. Incluso puedes enviar ambos encabezados, aplicar una política mientras se supervisa otra. Esta es una excelente manera de evaluar el efecto de los cambios en la CSP de tu aplicación: activa los informes para una política nueva, supervisa los informes de incumplimiento y corrige los errores que aparezcan. Cuando estés conforme con su efecto, comienza a aplicar la política nueva.

Uso en el mundo real

CSP 1 es bastante utilizable en Chrome, Safari y Firefox, pero tiene una compatibilidad muy limitada en IE 10. Puedes ver los detalles en caniuse.com. La CSP nivel 2 está disponible en Chrome desde la versión 40. Los sitios enormes como Twitter y Facebook implementaron el encabezado (vale la pena leer el caso de éxito de Twitter) y el estándar está muy listo para que comiences a implementarlo en tus propios sitios.

El primer paso a fin de crear una política para tu aplicación es evaluar los recursos que cargas en realidad. Una vez que creas que tienes claro cómo se organizan las cosas en tu app, configura una política que se base en esos requisitos. Analicemos algunos casos de uso comunes y determinemos la mejor manera de admitirlos dentro de los límites de protección de CSP.

Caso de uso n.o 1: Widgets de redes sociales

  • El botón de +1 de Google incluye una secuencia de comandos de https://apis.google.com e incorpora un <iframe> de https://plusone.google.com. Necesitas una política que incluya ambos orígenes para incorporar el botón. Una política mínima sería script-src https://apis.google.com; child-src https://plusone.google.com. También debes asegurarte de que el fragmento de JavaScript que Google proporciona se extraiga y se incluya en un archivo JavaScript externo. Si tenías una política basada en el nivel 1 que usa el nivel 2 de frame-src requería que la cambiaras a child-src. Esto ya no es necesario en el nivel de CSP 3.

  • El botón Me gusta de Facebook tiene varias opciones de implementación. Te recomendamos que uses la versión <iframe>, ya que puede ser una zona de pruebas segura del resto de tu sitio. Requiere una directiva child-src https://facebook.com para funcionar correctamente. Ten en cuenta que, de forma predeterminada, el código <iframe> que proporciona Facebook carga una URL relativa, //facebook.com. Cambia eso para especificar HTTPS de forma explícita: https://facebook.com. No hay razones para usar HTTP si no es necesario.

  • El botón de tweet de Twitter se basa en el acceso a una secuencia de comandos y un marco, ambos alojados en https://platform.twitter.com. (Asimismo, Twitter proporciona una URL relativa de forma predeterminada. Edita el código para especificar HTTPS cuando lo copies o pegues de forma local). Con script-src https://platform.twitter.com; child-src https://platform.twitter.com, estará todo listo, siempre que muevas el fragmento de JavaScript que proporciona Twitter a un archivo JavaScript externo.

  • Otras plataformas tienen requisitos similares y se pueden abordar de manera similar. Te sugerimos que simplemente configures un default-src de 'none' y que mires tu consola a fin de determinar qué recursos necesitarás habilitar para que funcionen los widgets.

Incluir varios widgets es sencillo: simplemente combina las directivas de la política y recuerda fusionar todos los recursos de un mismo tipo en una sola. Si quisieras los widgets de las tres redes sociales, la política se vería así:

script-src https://apis.google.com https://platform.twitter.com; child-src https://plusone.google.com https://facebook.com https://platform.twitter.com

Caso de uso n.o 2: Bloqueo

Imagina por un momento que diriges el sitio de un banco y quieres asegurarte de que solo se puedan cargar los recursos que escribiste. En esta situación, comienza con una política predeterminada que bloquee absolutamente todo (default-src 'none') y continúa desde allí.

Supongamos que el banco carga todas las imágenes, el estilo y la secuencia de comandos desde una CDN en https://cdn.mybank.net, y se conecta mediante XHR a https://api.mybank.com/ para extraer varios bits de datos. Se usan marcos, pero solo para páginas locales del sitio (sin orígenes de terceros). El sitio no cuenta con Flash, fuentes ni extras. El encabezado de CSP más restrictivo que podríamos enviar es el siguiente:

Content-Security-Policy: default-src 'none'; script-src https://cdn.mybank.net; style-src https://cdn.mybank.net; img-src https://cdn.mybank.net; connect-src https://api.mybank.com; child-src 'self'

Caso de uso n.o 3: Solo SSL

El administrador de un foro de debate sobre anillos de boda quiere asegurarse de que todos los recursos se carguen solo a través de canales seguros, pero en realidad no escribe mucho código. Volver a escribir grandes partes del software del foro de terceros que está lleno de secuencias de comandos y estilo intercalados está más allá de sus capacidades. La siguiente política sería efectiva:

Content-Security-Policy: default-src https:; script-src https: 'unsafe-inline'; style-src https: 'unsafe-inline'

Aunque https: se especifica en default-src, las directivas de estilo y secuencia de comandos no heredan automáticamente esa fuente. Cada directiva reemplaza por completo el valor predeterminado para ese tipo específico de recurso.

El futuro

La Política de Seguridad del Contenido de nivel 2 es una recomendación candidata. El grupo de trabajo de seguridad para aplicaciones web del W3C ya comenzó a trabajar en la próxima iteración de la especificación, la Política de Seguridad del Contenido de nivel 3.

Si te interesa el debate sobre estas próximas características, obtén una vista rápida de los archivos de la lista de distribución public-webappsec@ o únete.

Comentarios