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 defont-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 achild-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 descript-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, comoeval
. (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 deeval
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
osetInterval
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 deeval
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>
dehttps://plusone.google.com
Necesitas una política que incluya orígenes para incorporar el botón. Una política mínima seríascript-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 conframe-src
El nivel 2 te exigió que la cambiaras achild-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 directivachild-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 conscript-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.