Política de Seguridad del Contenido

El modelo de seguridad de la Web se basa en la política del mismo origen. El código de https://mybank.com solo debe tener acceso a los datos de https://mybank.com, y https://evil.example.com nunca debería tener acceso. Cada origen se mantiene aislado del resto de la Web, lo que brinda a los desarrolladores una zona de pruebas segura para compilar y jugar. En teoría, 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 política del mismo origen cuando engañan a un sitio para que entregue código malicioso junto con el contenido deseado. Esto es un gran problema, ya que los navegadores confían en que todo el código que aparece en una página es legítimamente parte del origen de seguridad de esa página. La hoja de referencia de XSS es una sección transversal antigua, pero representativa, de los métodos que un atacante podría usar para inyectar código malicioso y violar esta confianza. Si un atacante inyecta con éxito cualquier código, no es suficiente: se comprometen los datos de la sesión del usuario y la información que debe mantenerse en secreto se filtra a los malos. Obviamente, nos gustaría 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 las listas de entidades permitidas para indicarle al cliente lo que está permitido y lo que no.
• Obtén información sobre las directivas que están disponibles.
• Aprende las palabras clave que llevan.
• El código intercalado y eval() se consideran dañinos.
• Denuncia los incumplimientos de políticas en tu servidor antes de aplicarlos de manera forzosa.

Listas de entidades permitidas de fuentes

El problema que aprovechan los ataques de XSS es la incapacidad del navegador para distinguir entre la secuencia de comandos que forma parte de tu aplicación y la secuencia de comandos insertada de forma maliciosa por un tercero. Por ejemplo, el botón de +1 de Google al final 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 su cuenta 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 una página solicite, sin importar la fuente.

En lugar de confiar ciegamente en todo lo 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 los 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 solo permita que se ejecute 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 correctamente JavaScript de apis.google.com a través de HTTPS, así como del origen de la página actual.

Con esta política definida, 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 una página puede cargar. 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 en gran parte no está implementada 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 los 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 te puedes conectar (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 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 etiquetas <meta> y se aplica solo a recursos que no sean HTML.
• frame-src dejó de estar disponible en el nivel 2, pero se restableció en el nivel 3. Si no está presente, recurre 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 de contenido. Esta directiva no se puede usar 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 grandes cantidades de URL antiguas que deben reescribirse.
• worker-src es una directiva de nivel 3 de la CSP 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, como font-src, entonces esa directiva se comporta de forma predeterminada como si especificaras * como la fuente válida (por ejemplo, podrías cargar fuentes desde 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. Por lo general, esto se aplica a cualquier directiva que termine con -src. Si default-src se configura como https://example.com y no especificas una directiva font-src, podrás cargar fuentes desde https://example.com y de ningún otro lugar. En nuestros ejemplos anteriores, solo especificamos script-src, lo que significa que las imágenes, las fuentes, etc., se pueden cargar desde cualquier origen.

Las siguientes directivas no usan default-src como resguardo. Recuerda que no establecerlas es lo mismo que permitir todo.

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

Puedes usar tantas o pocas de estas directivas como sea necesario para tu aplicación específica. Solo tienes que enumerar cada una 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, la segunda directiva simplemente se ignorará. Algo como lo siguiente especificaría de forma correcta ambos orígenes como válidos:

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

Si, por ejemplo, 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 ningún complemento o contenido enmarcado, la política podría ser similar a lo 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 de la Web. En el futuro, deberías ignorar estos encabezados con prefijos. Los navegadores modernos (excepto IE) admiten el encabezado Content-Security-Policy sin prefijo. Ese es el encabezado que debes usar.

Sin importar el encabezado que uses, la política se define página por página: deberás enviar el encabezado HTTP junto con cada respuesta que quieras asegurarte de que esté protegida. Esto proporciona mucha flexibilidad, ya que puedes ajustar la política para páginas específicas según sus necesidades específicas. Es posible que un conjunto de páginas de tu sitio tenga un botón de +1, mientras que otros no: puedes permitir que el código del botón se cargue solo cuando sea necesario.

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

La lista de fuentes también acepta cuatro palabras clave:

• Como puedes esperar, 'none' 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 hablaremos de esto con más detalle).
• 'unsafe-eval' permite mecanismos de texto a JavaScript, como eval. (Ya veremos esto).

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 que JavaScript acceda desde un servidor llamado "self" (y no desde el host actual), que probablemente no sea lo que quisiste decir.

Zona de pruebas

Hay una directiva más que vale la pena mencionar: sandbox. Es un poco diferente de otras que vimos, ya que restringe las acciones que la página puede realizar en lugar de los recursos que puede cargar. Si está presente la directiva sandbox, la página se trata como si se hubiera cargado dentro de un <iframe> con un atributo sandbox. Esto puede tener una amplia variedad de efectos en la página: forzar la página a un origen único y evitar el envío de formularios, entre otros. 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 de HTML5.

La metaetiqueta

El mecanismo de entrega preferido de los 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 dañino.

Debería quedar claro que la CSP se basa en orígenes permitidos, ya que es una forma no ambigua de indicar al navegador que trate conjuntos específicos de recursos como aceptables y rechace el 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 alguna carga útil maliciosa (<script>sendMyDataToEvilDotCom();</script>), el navegador no tendrá un mecanismo para distinguirla de una etiqueta legítima de secuencia de comandos intercalada. La CSP resuelve este problema con la prohibición completa de las secuencias de comandos intercaladas: es la única forma de asegurarse.

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

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

en algo más como:

<!-- 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 una serie de ventajas que van más allá de funcionar bien con la CSP. Ya es una práctica recomendada, sin importar el uso que hagas de CSP. El JavaScript intercalado combina estructura y comportamiento exactamente de la manera que no deberías. Los recursos externos son más fáciles de almacenar en caché para los navegadores, más comprensibles para los desarrolladores y propician la compilación y la reducción. Escribirás mejor código si te dedicas a mover el código a recursos externos.

El diseño intercalado se trata de la misma manera: el atributo style y las etiquetas style deben consolidarse en hojas de estilo externas para proteger contra una variedad de métodos sorprendentemente inteligentes de robo de datos que CSS habilita.

Si necesitas tener una secuencia de comandos y un estilo intercalados, puedes habilitarlos agregando 'unsafe-inline' como una 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 debes hacerlo. Bloquear las secuencias de comandos intercaladas es la mayor victoria de seguridad que proporciona la CSP, y prohibir el estilo intercalado también endurece tu aplicación. Esfuérzate un poco por adelantado para asegurarte de que todo funcione correctamente después de mover todo el código fuera de línea, pero esa es una compensación que vale la pena.

Si debes usarlo

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

Para usar un nonce, asigna a tu etiqueta de secuencia de comandos un atributo nonce. 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 la directiva script-src junto a la palabra clave nonce-.

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

Recuerda que los nonces deben regenerarse 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 su página contiene lo siguiente:

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

Tu política contendría lo siguiente:

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

Debes 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 admite 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 al inicio o al final.

Una búsqueda de Google sobre cómo generar hashes de SHA te llevará a soluciones en cualquier cantidad de idiomas. Con Chrome 40 o versiones posteriores, puedes abrir Herramientas para desarrolladores y, luego, volver a cargar la página. La pestaña Console contendrá mensajes de error con el hash SHA256 correcto para cada una de tus secuencias de comandos intercaladas.

Eval también

Incluso cuando un atacante no puede insertar una secuencia de comandos directamente, es posible que engañe a tu aplicación para que convierta texto que de otro modo está 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 inesperadamente malicioso. La respuesta predeterminada del CSP a este riesgo es bloquear por completo todos estos vectores.

Esto afecta de varias formas la manera en que compilas 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 a partir de 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 cadenas. Por ejemplo:

setTimeout("document.querySelector('a').style.display = 'none';", 10);

quedaría mejor escrito de la siguiente manera:

setTimeout(function () {
  document.querySelector('a').style.display = 'none';
}, 10);

• Evita el uso de plantillas intercaladas durante el tiempo de ejecución, ya que muchas bibliotecas de plantillas usan new Function() sin restricciones para acelerar la generación de plantillas durante el tiempo de ejecución. Es una aplicación ingeniosa de programación dinámica, pero corre el riesgo de evaluar texto malicioso. Algunos frameworks admiten CSP de inmediato y recurre a un analizador sólido ante la 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 (por ejemplo, Handlebars lo hace). La precompilación de tus plantillas puede hacer que la experiencia del usuario sea aún más rápida que la implementación más rápida del tiempo de ejecución y también es más segura. Si eval y sus hermanos de texto a JavaScript son esenciales para tu aplicación, puedes habilitarlos si agregas 'unsafe-eval' como fuente permitida en una directiva script-src, pero no lo recomendamos. Bloquear la capacidad de ejecutar cadenas dificulta mucho que un atacante ejecute código no autorizado en tu sitio.

Reporte

La capacidad de la CSP de bloquear recursos que no son de confianza del lado del cliente es una gran ventaja para tus usuarios, pero sería bastante útil tener algún tipo de notificación enviada de vuelta al servidor para que puedas identificar y solucionar cualquier error que permita la inyección maliciosa en primer lugar. Para ello, puedes indicarle al navegador que POST los informes de incumplimiento 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"
  }
}

Contiene una buena información que te ayudará a rastrear la causa específica del incumplimiento, incluida la página en la que ocurrió el incumplimiento (document-uri), la URL de referencia de esa página (ten en cuenta que, 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 estás comenzando con CSP, tiene sentido evaluar el estado actual de tu aplicación antes de lanzar una política draconiana para tus usuarios. Como paso inicial para una implementación completa, puedes pedirle al navegador que supervise una política y que informe los incumplimientos, pero sin aplicar las restricciones de manera forzosa. 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 incumplimiento a la ubicación que especifiques. Incluso puedes enviar ambos encabezados, para 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: activar los informes para una política nueva, supervisar los informes de incumplimiento y corregir cualquier error que surja. Cuando estés conforme con su efecto, comienza a aplicar la nueva política.

Uso en el mundo real

CSP 1 se puede usar bastante en Chrome, Safari y Firefox, pero tiene una compatibilidad muy limitada en IE 10. Puedes ver detalles en caniuse.com. La CSP nivel 2 está disponible en Chrome desde la versión 40. Los sitios masivos como Twitter y Facebook implementaron el encabezado (vale la lectura del caso de éxito de Twitter), y el estándar está muy listo para que lo comiences a implementar en tus propios sitios.

El primer paso con el objetivo de crear una política para tu aplicación es evaluar los recursos que estás cargando. Cuando creas que tienes claro cómo se organizan los elementos en tu app, configura una política basada en esos requisitos. Veamos algunos casos de uso comunes y determinemos la mejor manera de admitirlos dentro de los límites de protección de la 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 proporciona Google se extraiga a un archivo JavaScript externo. Si tenías una política basada en el nivel 1 que usa el nivel 2 de frame-src, se te exigió que la cambiaras a child-src. Esto ya no es necesario en el nivel 3 de la CSP.

• El botón Me gusta de Facebook tiene varias opciones de implementación. Te recomendamos que conserves la versión <iframe>, ya que está protegida por 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 explícitamente HTTPS: https://facebook.com. No hay motivo para usar HTTP si no es necesario.

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

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

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

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

Supongamos 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 todo (default-src 'none') y compila a partir de allí.

Supongamos que el banco carga todas las imágenes, los estilos y las secuencias de comandos de una CDN en https://cdn.mybank.net y se conecta mediante XHR a https://api.mybank.com/ para extraer varios datos. Se usan marcos, pero solo para páginas locales del sitio (no para orígenes externos). En el sitio no hay 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 bodas desea asegurarse de que todos los recursos se carguen únicamente a través de canales seguros, pero en realidad no escribe mucho código. Volver a escribir grandes fragmentos del software de terceros para foros que está lleno de secuencias de comandos y estilos está fuera 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 la configuración predeterminada para ese tipo específico de recurso.

El futuro

El nivel 2 de la Política de Seguridad del Contenido es una recomendación candidata. El Grupo de trabajo de seguridad para aplicaciones web de 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 funciones, mira los archivos de la lista de distribución public-webappsec@ o únete por tu cuenta.

Comentarios