Política de Seguridad del Contenido

Mike West

Joe Medley

El modelo de seguridad de la Web se basa en política del mismo origen. Programación de https://mybank.com solo deben tener acceso a los archivos de https://mybank.com datos, y nunca se 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 espacio aislado en el que podrás compilar y jugar. En teoría, es brillante. En los atacantes han encontrado formas inteligentes de subvertir el sistema.

Secuencia de comandos entre sitios (XSS) evaden la misma política de origen al engañar a un sitio para que y entregar códigos maliciosos junto con el contenido previsto. Esta es una gran ya que los navegadores confían en que todo el código que aparece en una página que forman parte del origen de seguridad de esa página. El Hoja de referencia de XSS es una sección transversal antigua pero representativa de los métodos que un atacante podría usar inyectar código malicioso para infringir esta confianza. Si un atacante logra obtener inyecta cualquier código, ya casi termina el juego: los datos de la sesión del usuario vulneran y la información que debe ser secreta se exfiltra a los malos muchachos. Obviamente, nos gustaría evitarlo si es posible.

Esta visión general destaca una defensa que puede reducir significativamente el riesgo y impacto de los ataques de XSS en navegadores modernos: la Política de Seguridad del Contenido (CSP).

A modo de 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 es parte de tu aplicación y la secuencia de comandos que se ha que un tercero inyectó maliciosamente. Por ejemplo, el botón de +1 de Google en el al final de esta página carga y ejecuta código desde https://apis.google.com/js/plusone.js en el contexto del origen de esta página. Mié confiar en ese código, pero no podemos pretender que el navegador entienda ese código por su cuenta. 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 con alegría cualquier código de una página sin importar su origen.

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

Como confiamos en que apis.google.com entregará código válido y confiamos en nosotros mismos para hacer lo mismo, definamos una política que solo permita que se ejecute la secuencia de comandos proviene 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 secuencias 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 con el otro. El navegador debidamente descarga y ejecuta JavaScript de apis.google.com a través de HTTPS, así como desde el origen de la página actual.

Con esta política definida, el navegador simplemente muestra un error en lugar de cargando una secuencia de comandos desde cualquier otra fuente. Cuando un atacante inteligente logra inyectar código en el sitio, se encontrarán con un mensaje de error en lugar del éxito 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 evidentes, el CSP brinda un 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 debe ser clara.

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 se implementó en las navegadores.

• 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. Para ejemplo: child-src https://youtube.com habilitaría la incorporación de videos desde en 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. Web de Google las fuentes 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 solo se aplica a elementos que no son HTML de Google Cloud.
• frame-src dejó de estar disponible en el nivel 2, pero se restableció en el nivel 3. Si no es así presente sigue recurriendo 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 el navegador enviará informes cuando un elemento se infringe la política de seguridad de contenido. No se puede usar esta directiva en <meta> rótulos nuevos rápidamente.
• 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. cambiar HTTP a HTTPS. Esta directiva es para los sitios web con grandes cantidades de URL antiguas que necesitan volver a escribirse.
• worker-src es una directiva de nivel 3 de la CSP que restringe las URLs que posiblemente cargar como trabajador, trabajador compartido o service worker. A partir de julio de 2017, directiva tiene implementaciones limitadas.

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

Para anular este comportamiento predeterminado, especifica un default-src. directiva. Esta directiva define los valores predeterminados de la mayoría directivas que dejas sin especificar. Generalmente, esto se aplica a cualquier directiva que termina en -src. Si default-src se configura como https://example.com y fallas para especificar una directiva font-src, puedes cargar fuentes de https://example.com, y en ningún otro lugar. Especificamos solo script-src en nuestra ejemplos anteriores, lo que significa que las imágenes, las fuentes, etc., pueden cargarse desde cualquier origen.

Las siguientes directivas no usan default-src como resguardo. Recuerda que si no las estableces es lo mismo que permitir cualquier cosa.

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

Puedes usar tantas o pocas de estas directivas como sea necesario para tu una aplicación específica, con solo enumerarlas en el encabezado HTTP, separándolas directivas con punto y coma. Asegúrate de enumerar todas los recursos requeridos de un tipo específico en una única directiva. Si escribiste algo como script-src https://host1.com; script-src https://host2.com el se ignorará la segunda directiva. Algo como lo siguiente especificar correctamente 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 de una red de distribución de contenidos (por ejemplo, https://cdn.example.net) y sabrás que no necesitas complementos ni contenido enmarcado, es posible que el diseño de tu política de la siguiente manera:

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

Detalles de implementación

Verás los encabezados X-WebKit-CSP y X-Content-Security-Policy en varias instructivos en la Web. En el futuro, deberías ignorar las solicitudes con prefijos encabezados. Los navegadores modernos (excepto IE) admiten la API sin prefijo Encabezado Content-Security-Policy. Ese es el encabezado que debes usar.

Sin importar el encabezado que utilices, la política se define página por página: debes enviar el encabezado HTTP junto con cada respuesta que desees enviar garantizar que estén protegidos. Esto te brinda mucha flexibilidad, ya que puedes ajustar la política para páginas específicas según sus necesidades específicas. Quizás un conjunto de algunas páginas de tu sitio tengan un botón de +1, mientras que otras no: puedes permitir el código del botón solo se cargue cuando sea necesario.

La lista de fuentes en cada directiva es flexible. Puedes especificar fuentes esquema (data:, https:) o que varía en especificidad desde solo nombre de host (example.com, que coincide con cualquier origen en ese host: cualquier esquema, cualquier puerto) para un URI completamente calificado (https://example.com:443, que solo coincide con HTTPS, solo example.com y solo el puerto 443). Se aceptan comodines, pero solo como esquema, un puerto, o en la posición más a la izquierda del nombre de host: *://*.example.com:* le hacer coincidir todos los subdominios de example.com (pero no example.com en sí), con 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. (Hablaremos de esto en más detalle más adelante).
• 'unsafe-eval' permite mecanismos de texto a JavaScript, como eval. (Más adelante a 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 de que quizás no sea lo que querías 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 que puede tomar la página en lugar de en los recursos que esta puede cargar. Si el botón Si hay directiva sandbox, la página se trata como si se hubiera cargado dentro de una <iframe> con un atributo sandbox. Esto puede tener una amplia gama de efectos en la página: forzar a la página a un origen único y evitar que entre otros. Este artículo excede el alcance de este artículo, pero puedes encontrar todos los detalles sobre los atributos válidos de la zona de pruebas en la "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 para 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 un manera inequívoca de indicar al navegador que trate conjuntos específicos de recursos como aceptable y rechazar el resto. Las listas de entidades permitidas basadas en el origen no lo hacen, Sin embargo, resolverás 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 contenga directamente información carga útil (<script>sendMyDataToEvilDotCom();</script>), el navegador no tiene un mecanismo para distinguirlo de un etiqueta de secuencia de comandos intercalada. La CSP resuelve este problema al bloquear por completo las secuencias de comandos intercaladas: es la única forma de estar seguro.

Este bloqueo no solo incluye las secuencias de comandos incorporadas directamente en las etiquetas script, sino también controladores de eventos intercalados y las URLs javascript:. Deberás mover el contenido de Usa las etiquetas script en un archivo externo y reemplaza las URLs 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>

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 además de funcionar bien con CSP; ya es una práctica recomendada, sin importar el uso de CSP. Intercalados JavaScript mezcla 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 de aplicaciones y propiciar la compilación y la reducción. Escribirás mejor código si te dedicas a moverlo a recursos externos.

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

Si necesitas una secuencia de comandos y un estilo intercalados, puedes habilitarlos. Para ello, agrega 'unsafe-inline' como fuente permitida en una script-src o style-src. directiva. También puedes usar un nonce o un hash (consulta a continuación), pero realmente no debes hacerlo. Rechazar secuencias de comandos integradas es la mayor victoria de seguridad que proporciona el CSP. prohibir el estilo insertado también refuerza tu aplicación. Es un poco esfuerzo por adelantado para garantizar 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 hacer.

Si debes usarlo

La CSP nivel 2 ofrece retrocompatibilidad con secuencias de comandos integradas, ya que te permite agrega secuencias de comandos intercaladas específicas a la lista de entidades permitidas usando un nonce criptográfico (número una vez) o un hash. Aunque esto puede resultar engorroso, es útil si es necesario.

Para usar un nonce, asigna a tu etiqueta de secuencia de comandos un atributo nonce. Su valor debe coincidir con uno en 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'

Recuerde que los nonces deben regenerarse para cada solicitud de página y deben indescifrable.

Los hashes funcionan de la misma manera. En lugar de agregar código a la etiqueta de secuencia de comandos Crearás un hash SHA de la secuencia de comandos y lo agregarás 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-. el CSP también admite sha384- y sha512-. Cuando generes el hash, no incluyas el <script> etiquetas. También es importante el uso de mayúsculas y los espacios en blanco, incluido al principio o espacio en blanco al final.

Una búsqueda en Google sobre cómo generar hashes de SHA te llevará a soluciones en cualquier la cantidad de idiomas disponibles. Con Chrome 40 o versiones posteriores, puedes abrir Herramientas para desarrolladores y, luego, vuelve a cargar tu página. La pestaña Consola contendrá mensajes de error con la información hash sha256 para cada una de tus secuencias de comandos integradas.

Eval también

Incluso cuando un atacante no puede insertar una secuencia de comandos directamente, es posible que pueda engañar tu aplicación para que convierta texto que de otro modo no sería inerte en JavaScript ejecutable y ejecutarla en su nombre. eval(), nuevo Function(), setTimeout([string], ...) y setInterval([string], ...) son todos los vectores a través de los cuales se inyectan el texto podría terminar ejecutando algo inesperadamente malicioso. CSP predeterminado 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 JSON nativas están disponibles en en todos los navegadores desde Internet Explorer 8, y son completamente seguras.
• Vuelve a escribir las llamadas 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 un la excelente aplicación de la programación dinámica, pero corre el riesgo de evaluar textos maliciosos. Algunos frameworks admiten CSP de inmediato, recurrir a un analizador sólido en ausencia de eval 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 hace, por ejemplo). Precompilar tus plantillas puede hacer que la experiencia del usuario sea aún más más rápida que la implementación más rápida del tiempo de ejecución y, además, es más segura. Si evalúa y sus pares de texto a JavaScript son esenciales para tu aplicación, puedes Para habilitarlas, agrega 'unsafe-eval' como una fuente permitida en una script-src. directiva, pero no lo recomendamos. Bloquear la capacidad de ejecución cadenas de datos dificultan mucho más la ejecución no autorizada el código en tu sitio.

Informes

La capacidad del CSP de bloquear los recursos que no son de confianza del cliente es una gran ventaja para tu para los usuarios, pero sería útil tener algún tipo de notificación enviar de vuelta al servidor para que puedas identificar y neutralizar cualquier error que permita de una inyección maliciosa. Para ello, puedes indicar al navegador para POST informes de incumplimiento con formato JSON a una ubicación se especifica 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 mucha información que te ayudará a localizar causa específica de la infracción, incluida la página en la que se produjo (document-uri), la URL de referencia de esa página (ten en cuenta que, a diferencia de la encabezado, la clave no está mal escrita), el recurso que infringió la la política de la página (blocked-uri), la directiva específica que se 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 el estado de tu aplicación antes de lanzar una política draconiana para los usuarios. Para completar una implementación, puede pedirle al navegador que supervise una política, denunciar los incumplimientos, pero no aplicar las restricciones de manera forzosa. En lugar de envía 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 se enviarán los informes de incumplimiento a la ubicación que especifiques. Incluso puedes enviar ambos encabezados: se aplica una política mientras se supervisa otra. Esta es una excelente de evaluar el efecto de los cambios en la CSP de tu aplicación: activar de seguridad para una nueva política, supervisar los informes de incumplimiento y corregir cualquier error que sube el volumen; Cuando estés conforme con su efecto, comienza a aplicar la nueva política.

Uso en el mundo real

CSP 1 es bastante utilizable en Chrome, Safari y Firefox, pero tiene compatible con IE 10. Puedes consulta los detalles en caniuse.com. CSP nivel 2 está disponible en Chrome desde versión 40. Sitios masivos como Twitter y Facebook implementaron el encabezado Vale la pena leer el caso de éxito de Twitter, y el estándar está bastante listo. para que puedas comenzar a implementarlas en tus sitios.

El primer paso para crear una política para tu aplicación es evaluar la recursos que estás cargando. Cuando creas que sabes cómo elementos juntos en tu app, configura una política basada en y los requisitos de cumplimiento. Revisemos algunos casos de uso comunes y determinemos de respaldarlos dentro de los límites de protección de CSP.

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

• 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 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 necesitas para asegurarse de que el fragmento de JavaScript que proporciona Google se extraiga en un archivo JavaScript externo. Si tenías una política basada en el nivel 1 con frame-src El nivel 2 te exigió que la cambiaras a child-src. Ya no es necesario en CSP de nivel 3.

• Botón "Me gusta" de Facebook tiene varias opciones de implementación. Te recomendamos que sigas el versión de <iframe>, ya que está insertada en una zona de pruebas segura del resto de tu sitio. Integra requiere una directiva child-src https://facebook.com para funcionar correctamente. Nota que, de forma predeterminada, el código <iframe> que proporciona Facebook carga una unidad URL, //facebook.com. Cambia eso para especificar HTTPS de forma explícita: 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 default; edita el código para especificar HTTPS cuando lo copies y pegues de forma local). Siempre que muevas el fragmento de JavaScript, estará todo listo con script-src https://platform.twitter.com; child-src https://platform.twitter.com que Twitter proporciona en 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 y determinar qué recursos necesitas habilitar para que funcionen los widgets.

Incluir varios widgets es sencillo: simplemente combina la política de directivas de grupo, recuerda combinar todos los recursos de un solo tipo en un solo directiva. Si quisieras los widgets de las tres redes sociales, la política 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

Supongamos por un momento que diriges el sitio de un banco y quieres asegurarte solo se podrán cargar los recursos que tú mismo escribiste. En este caso, Comienza con una política predeterminada que bloquee todo (default-src 'none') y continúa con esa política.

Supongamos que el banco carga todas las imágenes, estilos y secuencias de comandos de una CDN en https://cdn.mybank.net y se conecta mediante XHR a https://api.mybank.com/ para extraer varios bits de datos. Se utilizan marcos, pero solo para páginas locales del (sin orígenes externos). El sitio no tiene Flash, fuentes ni fuentes adicionales. 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

Un administrador de un foro de debate sobre alianzas quiere asegurarse de que todos los recursos solo se carga a través de canales seguros, pero en realidad no escribe mucho código. reescribir grandes partes del software de terceros para foros que están llenos de guion y estilo intercalados 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, la secuencia de comandos y el estilo porque las directivas no heredan automáticamente esa fuente. Cada directiva es completamente reemplaza el valor predeterminado para ese tipo específico de recurso.

El futuro

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

Si te interesa el debate sobre estas próximas funciones, revisar los archivos de la lista de distribución public-webappsec@ o unirte tú mismo.

Comentarios