Una cuestión recurrente entre los dueños de sitios web consiste en elegir entre un no-www y www URLs. Esta página contiene algunos consejos sobre qué es mejor.
-
-
¿Qué son los nombres de dominio?
-
-
En una URL HTTP, la primera subcadena que sigue a la inicial http:// o https:// se llama nombre de dominio. El nombre de dominio está alojado en un servidor donde residen los documentos.
-
-
Un servidor no es necesariamente una máquina física: varios servidores pueden residir en la misma máquina física. O bien, un servidor puede ser manejado por varias máquinas, cooperando para producir la respuesta o equilibrando la carga de las solicitudes entre ellas. El punto clave es que semanticamente un nombre de dominio representa un solo servidor.
-
-
¿Entonces, ¿tengo que elegir uno u otro para mi sitio web?
-
-
-
Sí, tienes que elegir uno y seguir con él. La elección de cual tener como ubicación canónica es tuya, pero si eliges una, síguela. Esto hará tu sitio web parezca más consistente para tus usuarios y para los motores de búsqueda. Esto incluye siempre vincular al dominio elegido (lo que no debería ser difícil si está utilizando URLs relativas en su sitio web) y siempre compartir enlaces (por correo electrónico / redes sociales, etc.) al mismo dominio.
-
No, puedes tener dos. Lo que es importante es que seas coherente y consistente con cuál es el dominio oficial. A este dominio oficial se le llama nombre canónico. Todos tus enlaces absolutos deben usarlo. Pero, aun así, puedes seguir teniendo el otro dominio funcionando: HTTP permite dos técnicas para que esté claro para sus usuarios, o motores de búsqueda, cuyo dominio es el canónico, mientras permite que el dominio no-canónico funcione para proporcionar las páginas esperadas.
-
-
-
Por lo tanto, ¡elija uno de sus dominios como su canónico! Hay dos técnicas a continuación para permitir que el dominio no canónico funcione aún.
-
-
Técnicas para las URL canónicas.
-
-
Hay diferentes maneras de elegir qué sitio web es canónico.
-
-
Usando redirecciones HTTP 301
-
-
En este caso, necesitas configurar el servidor que recibe las peticiones HTTP (que probablemente sea el mismo para las URL www y no www) para responder con una respuesta HTTP adecuada {{HTTPStatus (301)}} a cualquier solicitud al dominio no-canónico. Esto redirigirá el navegador que intenta acceder a las URL no canónicas a su equivalente canónico. Por ejemplo, si ha elegido usar URL que no sean de www como tipo canónico, debe redirigir todas las URL de www a su URL equivalente sin el www.
-
-
Ejemplo:
-
-
-
Un servidor recibe una petición para http://www.example.org/whaddup (cuando el dominio canónico es example.org)
-
El servidor responde con un código {{HTTPStatus(301)}} con la cabecera {{HTTPHeader("Location")}}: http://example.org/whaddup.
-
El cliente emite una solicitud al dominio canónico.: http://example.org/whatddup
Es posible añadir un elemento especial HTML {{HTMLElement("link")}} a una página para indicar cual es la dirección canónica de la página. Esto no tendrá ningún impacto en la lectura humana, pero le dirá a rastreadores de los motores de búsqueda donde vive actualmente la página. De esta manera, los motores de búsqueda no indexan la misma página varias veces, lo que podría hacer que se considere contenido duplicado o correo no deseado, e incluso eliminar o bajar su página de las páginas de resultados del motor de búsqueda.
-
-
Al agregar una etiqueta de este tipo, sirve el mismo contenido para ambos dominios, indicando a los motores de búsqueda qué URL es canónica. En el ejemplo anterior, http://www.example.org/whaddup serviría el mismo contenido que http://example.org/whaddup, pero con un elemento {{htmlelement("link")}} adicional en la cabecera:
A diferencia del caso anterior, el historial del navegador considerará las direcciones URL no www y www como entradas independientes.
-
-
Hacer que tu página funcione para ambas
-
-
Con estas técnicas, puedes configurar tu servidor para responder correctamente a ambos dominios, www y no www. Es un buen consejo hacer esto, ya que no puede predecir qué URL escribirán los usuarios en la barra de URL de su navegador. Es una cuestión de elegir qué tipo desea usar como su ubicación canónica, y luego redirigir el otro tipo a él.
-
-
Decidir el caso
-
-
Este es un tema muy subjetivo que podría considerarse un problema de bikeshedding. Si desea leer más a fondo, lea algunos de los muchos artículos de este tema.
diff --git a/files/es/web/http/basics_of_http/choosing_between_www_and_non-www_urls/index.md b/files/es/web/http/basics_of_http/choosing_between_www_and_non-www_urls/index.md
new file mode 100644
index 00000000000000..725fc00dcacc03
--- /dev/null
+++ b/files/es/web/http/basics_of_http/choosing_between_www_and_non-www_urls/index.md
@@ -0,0 +1,65 @@
+---
+title: Elección entre www y no-www URLs
+slug: Web/HTTP/Basics_of_HTTP/Choosing_between_www_and_non-www_URLs
+tags:
+ - Guía
+ - HTTP
+ - URL
+ - WWW
+ - no www
+translation_of: Web/HTTP/Basics_of_HTTP/Choosing_between_www_and_non-www_URLs
+---
+{{HTTPSidebar}}
+
+Una cuestión recurrente entre los dueños de sitios web consiste en elegir entre un no-www y www URLs. Esta página contiene algunos consejos sobre qué es mejor.
+
+## ¿Qué son los nombres de dominio?
+
+En una URL HTTP, la primera subcadena que sigue a la inicial `http://` o `https://` se llama nombre de dominio. El nombre de dominio está alojado en un servidor donde residen los documentos.
+
+Un servidor no es necesariamente una máquina física: varios servidores pueden residir en la misma máquina física. O bien, un servidor puede ser manejado por varias máquinas, cooperando para producir la respuesta o equilibrando la carga de las solicitudes entre ellas. El punto clave es que semanticamente un nombre de dominio representa un solo servidor.
+
+## ¿Entonces, ¿tengo que elegir uno u otro para mi sitio web?
+
+- **Sí**, tienes que elegir uno y seguir con él. La elección de cual tener como ubicación canónica es tuya, pero si eliges una, síguela. Esto hará tu sitio web parezca más consistente para tus usuarios y para los motores de búsqueda. Esto incluye siempre vincular al dominio elegido (lo que no debería ser difícil si está utilizando URLs relativas en su sitio web) y siempre compartir enlaces (por correo electrónico / redes sociales, etc.) al mismo dominio.
+- **No**, puedes tener dos. Lo que es importante es que seas coherente y consistente con cuál es el dominio oficial. **A este dominio oficial se le llama nombre _canónico_.** Todos tus enlaces absolutos deben usarlo. Pero, aun así, puedes seguir teniendo el otro dominio funcionando: HTTP permite dos técnicas para que esté claro para sus usuarios, o motores de búsqueda, cuyo dominio es el canónico, mientras permite que el dominio no-canónico funcione para proporcionar las páginas esperadas.
+
+Por lo tanto, ¡elija uno de sus dominios como su canónico! Hay dos técnicas a continuación para permitir que el dominio no canónico funcione aún.
+
+## Técnicas para las URL canónicas.
+
+Hay diferentes maneras de elegir qué sitio web es _canónico_.
+
+### Usando redirecciones HTTP 301
+
+En este caso, necesitas configurar el servidor que recibe las peticiones HTTP (que probablemente sea el mismo para las URL www y no www) para responder con una respuesta HTTP adecuada {{HTTPStatus (301)}} a cualquier solicitud al dominio no-canónico. Esto redirigirá el navegador que intenta acceder a las URL no canónicas a su equivalente canónico. Por ejemplo, si ha elegido usar URL que no sean de www como tipo canónico, debe redirigir todas las URL de www a su URL equivalente sin el www.
+
+Ejemplo:
+
+1. Un servidor recibe una petición para `http://www.example.org/whaddup` (cuando el dominio canónico es example.org)
+2. El servidor responde con un código {{HTTPStatus(301)}} con la cabecera `{{HTTPHeader("Location")}}: http://example.org/whaddup`.
+3. El cliente emite una solicitud al dominio canónico.: `http://example.org/whatddup`
+
+El [HTML5 boilerplate project](https://github.com/h5bp/html5-boilerplate) tiene un ejemplo sobre [cómo configurar un servidor Apache para redirigir un dominio a otro](https://github.com/h5bp/html5-boilerplate/blob/7a22a33d4041c479d0962499e853501073811887/.htaccess#L219-L258).
+
+### `Usando `
+
+Es posible añadir un elemento especial HTML {{HTMLElement("link")}} a una página para indicar cual es la dirección canónica de la página. Esto no tendrá ningún impacto en la lectura humana, pero le dirá a rastreadores de los motores de búsqueda donde vive actualmente la página. De esta manera, los motores de búsqueda no indexan la misma página varias veces, lo que podría hacer que se considere contenido duplicado o correo no deseado, e incluso eliminar o bajar su página de las páginas de resultados del motor de búsqueda.
+
+Al agregar una etiqueta de este tipo, sirve el mismo contenido para ambos dominios, indicando a los motores de búsqueda qué URL es canónica. En el ejemplo anterior, `http://www.example.org/whaddup` serviría el mismo contenido que `http://example.org/whaddup`, pero con un elemento {{htmlelement("link")}} adicional en la cabecera:
+
+``
+
+A diferencia del caso anterior, el historial del navegador considerará las direcciones URL no www y www como entradas independientes.
+
+## Hacer que tu página funcione para ambas
+
+Con estas técnicas, puedes configurar tu servidor para responder correctamente a ambos dominios, www y no www. Es un buen consejo hacer esto, ya que no puede predecir qué URL escribirán los usuarios en la barra de URL de su navegador. Es una cuestión de elegir qué tipo desea usar como su ubicación canónica, y luego redirigir el otro tipo a él.
+
+## Decidir el caso
+
+Este es un tema muy subjetivo que podría considerarse un problema de [bikeshedding](http://bikeshed.com/). Si desea leer más a fondo, lea algunos de los [muchos artículos](http://www.themezilla.com/should-you-use-www-in-your-url-or-not/) de este tema.
+
+## Ver también
+
+- [Estadísticas sobre lo que la gente escribe en la barra de URL](https://www.chrisfinke.com/2011/07/25/what-do-people-type-in-the-address-bar/) (2011)
diff --git a/files/es/web/http/cors/errors/corsdidnotsucceed/index.html b/files/es/web/http/cors/errors/corsdidnotsucceed/index.html
deleted file mode 100644
index 9caf2fd86c4b70..00000000000000
--- a/files/es/web/http/cors/errors/corsdidnotsucceed/index.html
+++ /dev/null
@@ -1,48 +0,0 @@
----
-title: 'Reason: CORS request did not succeed'
-slug: Web/HTTP/CORS/Errors/CORSDidNotSucceed
-tags:
- - CORS
- - CORSNoTuvoExito
- - Consola
- - Error
- - HTTP
- - HTTPS
- - Messages
- - Reasons
- - Security
- - solución de problemas
-translation_of: Web/HTTP/CORS/Errors/CORSDidNotSucceed
----
-
{{HTTPSidebar}}
-
-
Razón
-
-
Razón: La solicitud CORS no resultó exitosa
-
-
-
¿Qué salió mal?
-
-
El pedido {{Glossary("HTTP")}} que hace uso de CORS falló porque la conexión HTTP falló a nivel red o protocolo. El error no está relacionado directamente con CORS, pero es un error de red fundamental de algún tipo
-
-
En muchos casos, es causado por un complemento del navegador (Ej, un bloqueador de anuncios o un protector de privacidad) que bloquea la solicitud.
-
-
Otras causas posibles:
-
-
-
Intentar acceder a un recurso https que tenga un certificado no válido, causará este error.
-
Intentar acceder a un recurso http desde una página con un origen https también causará este error.
-
A partir de Firefox 68, las páginas https no pueden acceder a http://localhost, aunque esto puede ser modificado por el Error 1488740.
-
El servidor no respondió a la solicitud actual (incluso si respondió la solicitud Preflight. Un escenario podría ser un servicio HTTP en desarrollo que "entró en pánico" sin devolver ningún dato.
diff --git a/files/es/web/http/cors/errors/corsdidnotsucceed/index.md b/files/es/web/http/cors/errors/corsdidnotsucceed/index.md
new file mode 100644
index 00000000000000..30d1a367baf7aa
--- /dev/null
+++ b/files/es/web/http/cors/errors/corsdidnotsucceed/index.md
@@ -0,0 +1,44 @@
+---
+title: 'Reason: CORS request did not succeed'
+slug: Web/HTTP/CORS/Errors/CORSDidNotSucceed
+tags:
+ - CORS
+ - CORSNoTuvoExito
+ - Consola
+ - Error
+ - HTTP
+ - HTTPS
+ - Messages
+ - Reasons
+ - Security
+ - solución de problemas
+translation_of: Web/HTTP/CORS/Errors/CORSDidNotSucceed
+---
+{{HTTPSidebar}}
+
+## Razón
+
+```
+Razón: La solicitud CORS no resultó exitosa
+```
+
+## ¿Qué salió mal?
+
+El pedido {{Glossary("HTTP")}} que hace uso de CORS falló porque la conexión HTTP falló a nivel red o protocolo. El error no está relacionado directamente con CORS, pero es un error de red fundamental de algún tipo
+
+En muchos casos, es causado por un complemento del navegador (Ej, un bloqueador de anuncios o un protector de privacidad) que bloquea la solicitud.
+
+Otras causas posibles:
+
+- Intentar acceder a un recurso `https` que tenga un certificado no válido, causará este error.
+- Intentar acceder a un recurso `http` desde una página con un origen `https` también causará este error.
+- A partir de Firefox 68, las páginas `https` no pueden acceder a `http://localhost`, aunque esto puede ser modificado por el [Error 1488740](https://bugzilla.mozilla.org/show_bug.cgi?id=1488740).
+- El servidor no respondió a la solicitud actual (incluso si respondió la [solicitud Preflight](/es/docs/Glossary/Preflight_peticion). Un escenario podría ser un servicio HTTP en desarrollo que "entró en pánico" sin devolver ningún dato.
+
+
+
+## Véase también
+
+- [Errores CORS](/es/docs/Web/HTTP/CORS/Errors)
+- Glosario: {{Glossary("CORS")}}
+- [Introducción a CORS](/es/docs/Web/HTTP/CORS)
diff --git a/files/es/web/http/cors/index.html b/files/es/web/http/cors/index.html
deleted file mode 100644
index 0c13bd7d00dd0c..00000000000000
--- a/files/es/web/http/cors/index.html
+++ /dev/null
@@ -1,439 +0,0 @@
----
-title: Control de acceso HTTP (CORS)
-slug: Web/HTTP/CORS
-translation_of: Web/HTTP/CORS
-original_slug: Web/HTTP/Access_control_CORS
----
-
{{HTTPSidebar}}
-
-
El Intercambio de Recursos de Origen Cruzado ({{Glossary("CORS")}}) es un mecanismo que utiliza cabeceras {{Glossary("HTTP")}} adicionales para permitir que un {{Glossary("user agent")}} obtenga permiso para acceder a recursos seleccionados desde un servidor, en un origen distinto (dominio) al que pertenece. Un agente crea una petición HTTP de origen cruzado cuando solicita un recurso desde un dominio distinto, un protocolo o un puerto diferente al del documento que lo generó.
-
-
Un ejemplo de solicitud de origen cruzado: el código JavaScript frontend de una aplicación web que es localizada en http://domain-a.com utiliza {{domxref("XMLHttpRequest")}} para cargar el recurso http://api.domain-b.com/data.json.
-
-
Por razones de seguridad, los exploradores restringen las solicitudes HTTP de origen cruzado iniciadas dentro de un script. Por ejemplo, XMLHttpRequest y la API Fetch siguen la política de mismo-origen. Ésto significa que una aplicación que utilice esas APIs XMLHttpRequest sólo puede hacer solicitudes HTTP a su propio dominio, a menos que se utilicen cabeceras CORS.
-
-
-
-
El W3CGrupo de Trabajo de Aplicaciones Web recomienda el nuevo mecanismo de Intercambio de Recursos de Origen Cruzado (CORS, por sus siglas en inglés). CORS da controles de acceso a dominios cruzados para servidores web y transferencia segura de datos en dominios cruzados entre navegadores y servidores Web. Los exploradores modernos utilizan CORS en un contenedor API (como XMLHttpRequest o Fetch) para ayudar a mitigar los riesgos de solicitudes HTTP de origen cruzado.
-
-
¿Quién debería leer este artículo?
-
-
Todo el mundo, de verdad.
-
-
Más específicamente, este artículo está dirigido a administradores web, desarrolladores de servidores y desarrolladores de interfaz. Los exploradores modernos manejan los componentes sobre el intercambio de origen cruzado del lado del cliente. Incluyendo cabeceras y políticas de ejecución. Pero, este nuevo estándar determina que los servidores tienen que manejar las nuevas solicitudes y las cabeceras de las respuestas. Se recomienda, como lectura suplementaria, otro artículo para desarrolladores de servidor que discute el intercambio de origen cruzado desde una perspectiva de servidor (con fragmentos de código PHP).
Este artículo es una discusión general sobre Intercambio de Recursos de Origin Cruzado e incluye una discusión sobre las cabeceras HTTP.
-
-
Resumen
-
-
El estándar de Intercambio de Recursos de Origen Cruzado trabaja añadiendo nuevas cabeceras HTTP que permiten a los servidores describir el conjunto de orígenes que tienen permiso para leer la información usando un explorador web. Adicionalmente, para métodos de solicitud HTTP que causan efectos secundarios en datos del usuario (y en particular, para otros métodos HTTP distintos a GET, o para la utilización de POST con algunos tipos MIME), la especificación sugiere que los exploradores "verifiquen" la solicitud, solicitando métodos soportados desde el servidor con un método de solicitud HTTP OPTIONS, y luego, con la "aprobación" del servidor, enviar la verdadera solicitud con el método de solicitud HTTP verdadero. Los servidores pueden también notificar a los clientes cuando sus "credenciales" (incluyendo Cookies y datos de autenticación HTTP) deben ser enviados con solicitudes.
-
-
Las secciones siguientes discuten escenarios, así como el análisis de las cabeceras HTTP usados.
-
-
Ejemplos de escenarios de control de accesos
-
-
Aquí, presentamos tres escenarios que ilustran cómo funciona el Intercambio de Recursos de Origen Cruzado. Todos estos ejemplos utilizan el objeto XMLHttpRequest, que puede ser utilizado para hacer invocaciones de sitios cruzados en cualquier explorador soportado.
Una solicitud de sitio cruzado es aquella que cumple las siguientes condiciones:
-
-
-
Los únicos métodos aceptados son:
-
-
GET
-
HEAD
-
POST.
-
-
-
Aparte de las cabeceras establecidas automáticamente por el agente usuario (ej. Connection, User-Agent,etc.), las únicas cabeceras que están permitidas para establecer manualmente son:
-
-
Accept
-
Accept-Language
-
Content-Language
-
Content-Type
-
-
-
Los únicos valores permitidos de la cabecera Content-Type son:
-
-
application/x-www-form-urlencoded
-
multipart/form-data
-
text/plain
-
-
-
-
-
Nota: Estos son los mismos tipos de solicitud de sitios cruzados que un contenido web ya puede emitir, y ninguna respuesta de datos es liberada a menos que el servidor envíe la cabecera apropiada. Por lo tanto, los sitios que prevengan solicitudes falsas de sitios cruzados no tienen nada nuevo que temer sobre el control de acceso HTTP.
-
-
Por ejemplo, suponga que el contenido web en el dominio http://foo.example desea invocar contenido en el dominio http://bar.other. Código de este tipo puede ser utilizado dentro de JavaScript desplegado en foo.example:
Las líneas 1 - 10 son las cabeceras enviadas por Firefox 3.5. Observe que la cabecera de solicitud HTTP principal aquí es la cabecera Origin: en la línea 10 de arriba, lo que muestra que la invocación proviene del contenido en el dominio http://foo.example.
-
-
Las líneas 13 - 22 muestran la respuesta HTTP del servidor en el dominio http://bar.other. En respuesta, el servidor envía de vuelta una cabecera Access-Control-Allow-Origin:, mostrado arriba en la línea 16. El uso de la cabecera Origin: y Access-Control-Allow-Origin: muestran el protocolo de control de acceso en su uso más simple. En este caso, el servidor responde con un Access-Control-Allow-Origin: * lo que significa que el recurso puede ser accedido por cualquier dominio en una forma de sitio cruzado. Si el dueño del recurso en http://bar.other deseara restringir el acceso al recurso solamente para http://foo.example, debería devolver lo siguiente:
-
-
Access-Control-Allow-Origin: http://foo.example
-
-
Note que ahora, ningún otro dominio aparte de http://foo.example (identificado por la cabecera ORIGIN: en la solicitud, como en la línea 10 arriba) puede acceder al recurso en una forma de sitio cruzado. La cabecera Access-Control-Allow-Origin debe contener el valor que fue enviado en la solicitud del encabezado Origin.
-
-
Solicitudes Verificadas
-
-
A diferencia de las solicitudes simples (discutidas arriba), las solicitudes "verificadas" envían primero una solicitud HTTP por el método OPTIONS al recurso en el otro dominio, para determinar si es seguro enviar la verdadera solicitud. Las solicitudes de sitios cruzados son verificadas así ya que pueden tener implicaciones en la información de usuario. En particular, una solicitud es verificada sí:
-
-
-
Usa métodos distintos a GET, HEADo POST. También, si POST es utilizado para enviar solicitudes de información con Content-Type distinto a application/x-www-form-urlencoded, multipart/form-data, o text/plain, ej. si la solicitud POST envía una carga XML al servidor utilizando application/xml or text/xml, entonces la solicitud es verificada.
-
Se establecen encabezados personalizados (ej. la solicitud usa un encabezado como X-PINGOTHER)
-
-
-
-
Nota: Empezando en {{Gecko("2.0")}}, las codificaciones de datos text/plain, application/x-www-form-urlencoded, y multipart/form-data pueden ser enviadas en sitios cruzados sin verificación. Anteriormente, solo text/plain podía ser enviado sin verificación.
En el ejemplo de arriba, la línea 3 crea un cuerpo XML para enviar con la solicitud POST en la línea 8. También, en la línea 9, se establece una cabecera HTTP de solicitud "personalizado" (no estándar X-PINGOTHER: pingpong). Dichas cabeceras no son parte del protocolo HTTP/1.1, pero son útiles generalmente en aplicaciones web. Dado que la solicitud (POST) usa un Content-Type application/xml, y dado que se establece una cabecera personalizada, la solicitud es verificada.
-
-
Veamos este intercambio completo entre un cliente y un servidor:
Las líneas 1 - 12 arriba representan la solicitud verificada con los métodos OPTIONS. Firefox 3.1 determina lo que se necesita para enviar esto basándose en los parámetros de la solicitud que los fragmentos de JavaScript que se usaron arriba, para que el servidor pueda responder si es aceptable enviar la solicitud con los parámetros de la solicitud real. OPTIONS es un método HTTP/1.1 que se utiliza para determinar información adicional de los servidores, y es un método idempotente, esto significa que no puede ser utilizado para cambiar el recurso. Observe que, junto con la solicitud OPTIONS, se envían otras dos cabeceras de solicitud (líneas 11 y 12 respectivamente):
-
-
Access-Control-Request-Method: POST
-Access-Control-Request-Headers: X-PINGOTHER
-
-
-
La cabecera Access-Control-Request-Method notifica al servidor como parte de una solicitud verificada que cuándo se envíe la solicitud real, esta será enviada con un método de solicitud POST. La cabecera Access-Control-Request-Headers notifica al servidor que cuando la solicitud real sea enviada, será enviada con un encabezado X-PINGOTHER personalizado. Ahora, el servidor tiene la oportunidad para determinar si desea aceptar la solicitud bajo estas circunstancias.
-
-
Las líneas 15 - 27 de arriba corresponden con la respuesta que devuelve el servidor indicando que el método de la petición (POST) y la cabecera X-PINGOTHER son aceptadas. En particular, echemos un vistazo a las líneas 18-21:
-
-
Access-Control-Allow-Origin: http://foo.example
-Access-Control-Allow-Methods: POST, GET, OPTIONS
-Access-Control-Allow-Headers: X-PINGOTHER
-Access-Control-Max-Age: 1728000
-
-
El servidor responde con Access-Control-Allow-Methods y dice que POST, GET, y OPTIONS son métodos viables para consultar el recurso en cuestión. Observe que esta cabecera es similar al HTTP/1.1 Allow: encabezado de respuesta, pero usado estrictamente dentro del contexto del control de acceso. El servidor también envía Access-Control-Allow-Headers con un valor de X-PINGOTHER, confirmando que es una cabecera permitida para ser usado en la solicitud real. Como Access-Control-Allow-Methods, Access-Control-Allow-Headers es una lista separada por comas de cabeceras aceptables. Finalmente, Access-Control-Max-Age da el valor en segundos de cuánto tarda la respuesta de la solicitud verificada en ser capturada sin enviar otra solicitud verificada. En este caso, 1728000 segundos son 20 días.
-
-
Solicitudes con credenciales
-
-
La capacidad más interesante expuesta tanto por XMLHttpRequest y Access Control es la habilidad para hacer solicitudes "con credenciales" que estén al tanto de Cookies HTTP e información de Autenticación HTTP. Por defecto, en las invocaciones XMLHttpRequest de un sitio curzado, los exploradores no enviarán credenciales. Una bandera específica tiene que ser establecida en el objeto XMLHttpRequest cuando este es invocado.
-
-
En este ejemplo, el contenido cargado originalmente desde http://foo.example hace una solicitud GET simple a un recurso en http://bar.other que establece Cookies. El contenido en foo.example puede contener un JavaScript como este:
La línea 7 muestra la bandera en XMLHttpRequest que tiene que ser establecida para poder hacer la invocación con Cookies, es decir, el valor booleano withCredentials. Por defecto, la invocación es hecha sin Cookies. Dado que esta es una simple solicitud GET, no es verificada, pero el explorador rechazará cualquier respuesta que no tiene el encabezado Access-Control-Allow-Credentials: true,y no hará disponible la respuesta para invocar contenido web.
-
-
A continuación se proporciona una muestra de intercambio entre un cliente y un servidor:
Pese a que la línea 11 contiene la Cookie destinada para el contenido en http://bar.other, si bar.other no responde con Access-Control-Allow-Credentials: true (línea 19) la respuesta será ignorada y no puesta a disposición para el contenido web. Nota Importante: cuando se responde a una solicitud con credeciales, el servidor debeespecificar un dominio, y no puede usar comodines. El ejemplo de arriba fallará si la cabecera fuera un comodín como: Access-Control-Allow-Origin: *. Dado que Access-Control-Allow-Origin menciona explícitamente http://foo.example, el contenido de credenciales competente es devuelto al contenido web invocador. Observe que, en la línea 22, se establece una cookie adicional.
-
-
Todos estos ejemplos pueden verse funcionando aquí. La siguiente sección se refiere a las verdaderas cabeceras HTTP.
-
-
Las cabeceras HTTP de respuesta
-
-
Esta sección lista las cabeceras HTTP de respuesta que los servidores envían de vuelta para las solicitudes de acceso de control definidas por la especificación del Intercambio de Recursos de Origen Cruzado. La sección anterior da un resumen de estos en acción.
-
-
Access-Control-Allow-Origin
-
-
Un recurso devuelto puede tener una cabecera Access-Control-Allow-Origin, con la siguiente sintaxis:
-
-
Access-Control-Allow-Origin: <origin> | *
-
-
-
El parámetro origin específica una URI que puede tener acceso al recurso. El explorador debe asegurar esto. Para solicitudes sin credenciales, el servidor debe especificar "*" como un comodín permitiendo, de este modo, el acceso al recurso a cualquier origen.
-
-
Por ejemplo, para permitir a http://mozilla.com acceder al recurso, usted puede especificar:
-
-
Access-Control-Allow-Origin: http://mozilla.com
-
-
Si el servidor especifica un host de origen en vez de "*", entonces se debe incluir Origin en el encabezado de respuesta Vary para indicar a los clientes que las respuestas del servidor difieren basándose en el valor del encabezado de respuestaOrigin.
-
-
Access-Control-Expose-Headers
-
-
Esta cabecera permite una whitelist de cabeceras del servidor que los exploradores tienen permitido acceder. Por ejemplo:
Esto permite a las cabeceras X-My-Custom-Header y X-Another-Custom-Header ser expuestos al explorador.
-
-
Access-Control-Max-Age
-
-
Esta cabecera indica durante cuánto tiempo los resultados de la solicitud verificada pueden ser capturados. Para un ejemplo de solicitudes verificadas, vea los ejemplos de arriba.
-
-
Access-Control-Max-Age: <delta-seconds>
-
-
-
El parámetro delta-seconds indica el número de segundos en que los resultados pueden ser capturados.
-
-
Access-Control-Allow-Credentials
-
-
Indica si la respuesta puede ser expuesta cuando la bandera credentials es verdadera. Cuando se usa como parte de una respuesta para una solicitud verficada, este indica si la solicitud verdadera puede realizarse usando credenciales. Note que las solicitudes GET simples no son verificadas, y por lo que si una solicitud es hecha para un recurso con credenciales, si la cabecera no es devuelta con el recurso, la respuesta es ignorada por el explorador y no devuelta al contenido web.
Específica el método o los métodos permitidos cuando se asigna un recurso. Es usado en respuesta a la solicitud verificada. Las condiciones sobre cuándo una solicitud es verificada se discuten arriba.
Esta sección lista las cabeceras que los clietnes deben utilizar cuando realizan solicitudes HTTP para usar la característica de intercambio de origen cruzado. Note que estas cabeceras son establecidas cuando se realizan realizan invocaciones a los servidores. Los desarrolladores usan la capacidad de sitios cruzados XMLHttpRequest para no tener que establecer ninguna solicitud de intercambio de origen cruzado programada.
-
-
Origin
-
-
Indica el origen de las solicitudes de acceso a sitios cruzados o solicitudes verificadas.
-
-
Origin: <origin>
-
-
-
El origen es una URI indicando al servidor dónde se ha iniciado la solicitud. Este no incluye ninguna información de recorrido, sólo el nombre del servidor.
-
-
Nota: El origin puede ser un string vacío; esto es útil, por ejemplo, si el recurso es un data URL.
-
-
Observe que en cualquier solicitud de acceso de control, la cabecera ORIGINsiempre se envía.
-
-
Access-Control-Request-Method
-
-
Se usa cuando se emite una solicitud verificada, para indicarle al servidor qué método HTTP será usado cuando se haga la solicitud real.
-
-
Access-Control-Request-Method: <method>
-
-
-
Ejemplos de esta utilización pueden ser encontrados arriba.
-
-
Access-Control-Request-Headers
-
-
Usada cuando se emite una solicitud verificada para indicarle al servidor qué cabecera HTTP será usada cuando se haga la solicitud real.
diff --git a/files/es/web/http/cors/index.md b/files/es/web/http/cors/index.md
new file mode 100644
index 00000000000000..c88cd06fcaa422
--- /dev/null
+++ b/files/es/web/http/cors/index.md
@@ -0,0 +1,429 @@
+---
+title: Control de acceso HTTP (CORS)
+slug: Web/HTTP/CORS
+translation_of: Web/HTTP/CORS
+original_slug: Web/HTTP/Access_control_CORS
+---
+{{HTTPSidebar}}
+
+El Intercambio de Recursos de Origen Cruzado ({{Glossary("CORS")}}) es un mecanismo que utiliza cabeceras {{Glossary("HTTP")}} adicionales para permitir que un {{Glossary("user agent")}} obtenga permiso para acceder a recursos seleccionados desde un servidor, en un origen distinto (dominio) al que pertenece. Un agente crea una petición HTTP de origen cruzado cuando solicita un recurso desde un dominio distinto, un protocolo o un puerto diferente al del documento que lo generó.
+
+Un ejemplo de solicitud de origen cruzado: el código JavaScript frontend de una aplicación web que es localizada en `http://domain-a.com` utiliza {{domxref("XMLHttpRequest")}} para cargar el recurso `http://api.domain-b.com/data.json`.
+
+Por razones de seguridad, los exploradores restringen las solicitudes HTTP de origen cruzado iniciadas dentro de un script. Por ejemplo, [XMLHttpRequest](/es/docs/Web/API/XMLHttpRequest) y la API [Fetch](/es/docs/Web/API/Fetch_API) siguen la [política de mismo-origen](/es/docs/Web/Security/Same-origin_policy). Ésto significa que una aplicación que utilice esas APIs [XMLHttpRequest](/es/docs/Web/API/XMLHttpRequest) sólo puede hacer solicitudes HTTP a su propio dominio, a menos que se utilicen cabeceras CORS.
+
+
+
+El [W3C](http://www.w3.org/) [Grupo de Trabajo de Aplicaciones Web](http://www.w3.org/2008/webapps/) recomienda el nuevo mecanismo de [Intercambio de Recursos de Origen Cruzado](http://www.w3.org/TR/cors/) (CORS, por sus siglas en inglés). CORS da controles de acceso a dominios cruzados para servidores web y transferencia segura de datos en dominios cruzados entre navegadores y servidores Web. Los exploradores modernos utilizan CORS en un **contenedor API** (como [XMLHttpRequest](/es/docs/Web/API/XMLHttpRequest) o [Fetch](/es/docs/Web/API/Fetch_API)) para ayudar a mitigar los riesgos de solicitudes HTTP de origen cruzado.
+
+## ¿Quién debería leer este artículo?
+
+Todo el mundo, de verdad.
+
+Más específicamente, este artículo está dirigido a administradores web, desarrolladores de servidores y desarrolladores de interfaz. Los exploradores modernos manejan los componentes sobre el intercambio de origen cruzado del lado del cliente. Incluyendo cabeceras y políticas de ejecución. Pero, este nuevo estándar determina que los servidores tienen que manejar las nuevas solicitudes y las cabeceras de las respuestas. Se recomienda, como lectura suplementaria, otro artículo para desarrolladores de servidor que discute el [intercambio de origen cruzado desde una perspectiva de servidor (con fragmentos de código PHP)](/es/docs/Web/HTTP/Server-Side_Access_Control).
+
+## ¿Qué peticiones utiliza CORS?
+
+Este [estándar de intercambio de origen cruzado](http://www.w3.org/TR/cors/) es utilizado para habilitar solicitudes HTTP de sitios cruzados para:
+
+- Invocaciones de las APIs [`XMLHttpRequest`](/en/DOM/XMLHttpRequest) o [Fetch](/es/docs/Web/API/Fetch_API) en una manera de sitio cruzado, como se discutió arriba.
+- Fuentes Web (para usos de fuente en dominios cruzados `@font-face` dentro de CSS), [para que los servidores puedan mostrar fuentes TrueType que sólo puedan ser cargadas por sitios cruzados y usadas por sitios web que lo tengan permitido.](https://www.w3.org/TR/css-fonts-3/#font-fetching-requirements)
+- Texturas WebGL.
+- Imágenes dibujadas en patrones usando [`drawImage`](https://developer.mozilla.org/en-US/docs/Web/API/CanvasRenderingContext2D/drawImage).
+- Hojas de estilo (para acceso [CSSOM](/es/docs/Web/CSS/CSSOM_View)).
+- Scripts (para excepciones inmutadas).
+
+Este artículo es una discusión general sobre Intercambio de Recursos de Origin Cruzado e incluye una discusión sobre las cabeceras HTTP.
+
+## Resumen
+
+El estándar de Intercambio de Recursos de Origen Cruzado trabaja añadiendo nuevas cabeceras HTTP que permiten a los servidores describir el conjunto de orígenes que tienen permiso para leer la información usando un explorador web. Adicionalmente, para métodos de solicitud HTTP que causan efectos secundarios en datos del usuario (y en particular, para otros métodos HTTP distintos a `GET`, o para la utilización de `POST` con algunos tipos MIME), la especificación sugiere que los exploradores "verifiquen" la solicitud, solicitando métodos soportados desde el servidor con un método de solicitud HTTP `OPTIONS`, y luego, con la "aprobación" del servidor, enviar la verdadera solicitud con el método de solicitud HTTP verdadero. Los servidores pueden también notificar a los clientes cuando sus "credenciales" (incluyendo Cookies y datos de autenticación HTTP) deben ser enviados con solicitudes.
+
+Las secciones siguientes discuten escenarios, así como el análisis de las cabeceras HTTP usados.
+
+## Ejemplos de escenarios de control de accesos
+
+Aquí, presentamos tres escenarios que ilustran cómo funciona el Intercambio de Recursos de Origen Cruzado. Todos estos ejemplos utilizan el objeto [`XMLHttpRequest`](/en/DOM/XMLHttpRequest), que puede ser utilizado para hacer invocaciones de sitios cruzados en cualquier explorador soportado.
+
+Los fragmentos de JavaScript incluidos en estas secciones (y las instancias ejecutadas del código servidor que correctamente maneja las solicitudes de sitios cruzados) [pueden ser encontrados "en acción" aquí](http://arunranga.com/examples/access-control/), y pueden ser trabajados en exploradores que soportan [`XMLHttpRequest`](/en/DOM/XMLHttpRequest) de sitios cruzados. Una discusión de Intercambio de Recursos de Origen Cruzado desde una [perspectiva de servidor (incluyendo fragmentos de código PHP) puede ser encontrada aquí](/es/docs/Web/HTTP/Server-Side_Access_Control).
+
+### Solicitudes simples
+
+Una solicitud de sitio cruzado es aquella que cumple las siguientes condiciones:
+
+- Los únicos métodos aceptados son:
+
+ - GET
+ - HEAD
+ - POST.
+
+- Aparte de las cabeceras establecidas automáticamente por el agente usuario (ej. `Connection, User-Agent,`etc.), las únicas cabeceras que están permitidas para establecer manualmente son:
+
+ - `Accept`
+ - `Accept-Language`
+ - `Content-Language`
+ - `Content-Type`
+
+- Los únicos valores permitidos de la cabecera `Content-Type` son:
+
+ - `application/x-www-form-urlencoded`
+ - `multipart/form-data`
+ - `text/plain`
+
+> **Nota:** Estos son los mismos tipos de solicitud de sitios cruzados que un contenido web ya puede emitir, y ninguna respuesta de datos es liberada a menos que el servidor envíe la cabecera apropiada. Por lo tanto, los sitios que prevengan solicitudes falsas de sitios cruzados no tienen nada nuevo que temer sobre el control de acceso HTTP.
+
+Por ejemplo, suponga que el contenido web en el dominio `http://foo.example` desea invocar contenido en el dominio `http://bar.other`. Código de este tipo puede ser utilizado dentro de JavaScript desplegado en foo.example:
+
+```js
+var invocation = new XMLHttpRequest();
+var url = 'http://bar.other/resources/public-data/';
+
+function callOtherDomain() {
+ if(invocation) {
+ invocation.open('GET', url, true);
+ invocation.onreadystatechange = handler;
+ invocation.send();
+ }
+}
+```
+
+Dejándonos ver lo que el explorador enviará al servidor en este caso, y veamos como responde el servidor:
+
+```shell
+GET /resources/public-data/ HTTP/1.1
+Host: bar.other
+User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
+Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
+Accept-Language: en-us,en;q=0.5
+Accept-Encoding: gzip,deflate
+Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
+Connection: keep-alive
+Referer: http://foo.example/examples/access-control/simpleXSInvocation.html
+Origin: http://foo.example
+
+
+HTTP/1.1 200 OK
+Date: Mon, 01 Dec 2008 00:23:53 GMT
+Server: Apache/2.0.61
+Access-Control-Allow-Origin: *
+Keep-Alive: timeout=2, max=100
+Connection: Keep-Alive
+Transfer-Encoding: chunked
+Content-Type: application/xml
+
+[XML Data]
+```
+
+Las líneas 1 - 10 son las cabeceras enviadas por Firefox 3.5. Observe que la cabecera de solicitud HTTP principal aquí es la cabecera `Origin:` en la línea 10 de arriba, lo que muestra que la invocación proviene del contenido en el dominio `http://foo.example`.
+
+Las líneas 13 - 22 muestran la respuesta HTTP del servidor en el dominio `http://bar.other`. En respuesta, el servidor envía de vuelta una cabecera `Access-Control-Allow-Origin:`, mostrado arriba en la línea 16. El uso de la cabecera `Origin:` y `Access-Control-Allow-Origin:` muestran el protocolo de control de acceso en su uso más simple. En este caso, el servidor responde con un `Access-Control-Allow-Origin: *` lo que significa que el recurso puede ser accedido por **cualquier** dominio en una forma de sitio cruzado. Si el dueño del recurso en `http://bar.other` deseara restringir el acceso al recurso solamente para `http://foo.example`, debería devolver lo siguiente:
+
+`Access-Control-Allow-Origin: http://foo.example`
+
+Note que ahora, ningún otro dominio aparte de `http://foo.example` (identificado por la cabecera ORIGIN: en la solicitud, como en la línea 10 arriba) puede acceder al recurso en una forma de sitio cruzado. La cabecera Access-Control-Allow-Origin debe contener el valor que fue enviado en la solicitud del encabezado `Origin.`
+
+### Solicitudes Verificadas
+
+A diferencia de las solicitudes simples (discutidas arriba), las solicitudes "verificadas" envían primero una solicitud HTTP por el método `OPTIONS` al recurso en el otro dominio, para determinar si es seguro enviar la verdadera solicitud. Las solicitudes de sitios cruzados son verificadas así ya que pueden tener implicaciones en la información de usuario. En particular, una solicitud es verificada sí:
+
+- Usa métodos **distintos** a `GET, HEAD` `o POST`. También, si `POST` es utilizado para enviar solicitudes de información con Content-Type **distinto** a`application/x-www-form-urlencoded`, `multipart/form-data`, o `text/plain`, ej. si la solicitud `POST` envía una carga XML al servidor utilizando `application/xml` or `text/xml`, entonces la solicitud **es** verificada.
+- Se establecen encabezados personalizados (ej. la solicitud usa un encabezado como `X-PINGOTHER`)
+
+> **Nota:** Empezando en {{Gecko("2.0")}}, las codificaciones de datos `text/plain`, `application/x-www-form-urlencoded`, y `multipart/form-data` pueden ser enviadas en sitios cruzados sin verificación. Anteriormente, solo`text/plain` podía ser enviado sin verificación.
+
+Un ejemplo de este tipo de invocación puede ser:
+
+```js
+var invocation = new XMLHttpRequest();
+var url = 'http://bar.other/resources/post-here/';
+var body = 'Arun';
+
+function callOtherDomain(){
+ if(invocation)
+ {
+ invocation.open('POST', url, true);
+ invocation.setRequestHeader('X-PINGOTHER', 'pingpong');
+ invocation.setRequestHeader('Content-Type', 'application/xml');
+ invocation.onreadystatechange = handler;
+ invocation.send(body);
+ }
+}
+
+......
+```
+
+En el ejemplo de arriba, la línea 3 crea un cuerpo XML para enviar con la solicitud `POST` en la línea 8. También, en la línea 9, se establece una cabecera HTTP de solicitud "personalizado" (no estándar `X-PINGOTHER: pingpong`). Dichas cabeceras no son parte del protocolo HTTP/1.1, pero son útiles generalmente en aplicaciones web. Dado que la solicitud (`POST`) usa un Content-Type `application/xml`, y dado que se establece una cabecera personalizada, la solicitud es verificada.
+
+Veamos este intercambio completo entre un cliente y un servidor:
+
+```shell
+OPTIONS /resources/post-here/ HTTP/1.1
+Host: bar.other
+User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
+Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
+Accept-Language: en-us,en;q=0.5
+Accept-Encoding: gzip,deflate
+Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
+Connection: keep-alive
+Origin: http://foo.example
+Access-Control-Request-Method: POST
+Access-Control-Request-Headers: X-PINGOTHER
+
+
+HTTP/1.1 200 OK
+Date: Mon, 01 Dec 2008 01:15:39 GMT
+Server: Apache/2.0.61 (Unix)
+Access-Control-Allow-Origin: http://foo.example
+Access-Control-Allow-Methods: POST, GET, OPTIONS
+Access-Control-Allow-Headers: X-PINGOTHER
+Access-Control-Max-Age: 1728000
+Vary: Accept-Encoding, Origin
+Content-Encoding: gzip
+Content-Length: 0
+Keep-Alive: timeout=2, max=100
+Connection: Keep-Alive
+Content-Type: text/plain
+
+POST /resources/post-here/ HTTP/1.1
+Host: bar.other
+User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
+Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
+Accept-Language: en-us,en;q=0.5
+Accept-Encoding: gzip,deflate
+Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
+Connection: keep-alive
+X-PINGOTHER: pingpong
+Content-Type: text/xml; charset=UTF-8
+Referer: http://foo.example/examples/preflightInvocation.html
+Content-Length: 55
+Origin: http://foo.example
+Pragma: no-cache
+Cache-Control: no-cache
+
+Arun
+
+
+HTTP/1.1 200 OK
+Date: Mon, 01 Dec 2008 01:15:40 GMT
+Server: Apache/2.0.61 (Unix)
+Access-Control-Allow-Origin: http://foo.example
+Vary: Accept-Encoding, Origin
+Content-Encoding: gzip
+Content-Length: 235
+Keep-Alive: timeout=2, max=99
+Connection: Keep-Alive
+Content-Type: text/plain
+
+[Some GZIP'd payload]
+```
+
+Las líneas 1 - 12 arriba representan la solicitud verificada con los métodos `OPTIONS`. Firefox 3.1 determina lo que se necesita para enviar esto basándose en los parámetros de la solicitud que los fragmentos de JavaScript que se usaron arriba, para que el servidor pueda responder si es aceptable enviar la solicitud con los parámetros de la solicitud real. OPTIONS es un método HTTP/1.1 que se utiliza para determinar información adicional de los servidores, y es un método **idempotente**, esto significa que no puede ser utilizado para cambiar el recurso. Observe que, junto con la solicitud OPTIONS, se envían otras dos cabeceras de solicitud (líneas 11 y 12 respectivamente):
+
+```
+Access-Control-Request-Method: POST
+Access-Control-Request-Headers: X-PINGOTHER
+```
+
+La cabecera `Access-Control-Request-Method` notifica al servidor como parte de una solicitud verificada que cuándo se envíe la solicitud real, esta será enviada con un método de solicitud `POST`. La cabecera `Access-Control-Request-Headers` notifica al servidor que cuando la solicitud real sea enviada, será enviada con un encabezado `X-PINGOTHER` personalizado. Ahora, el servidor tiene la oportunidad para determinar si desea aceptar la solicitud bajo estas circunstancias.
+
+Las líneas 15 - 27 de arriba corresponden con la respuesta que devuelve el servidor indicando que el método de la petición (POST) y la cabecera `X-PINGOTHER` son aceptadas. En particular, echemos un vistazo a las líneas 18-21:
+
+```
+Access-Control-Allow-Origin: http://foo.example
+Access-Control-Allow-Methods: POST, GET, OPTIONS
+Access-Control-Allow-Headers: X-PINGOTHER
+Access-Control-Max-Age: 1728000
+```
+
+El servidor responde con `Access-Control-Allow-Methods` y dice que `POST`, `GET`, y `OPTIONS` son métodos viables para consultar el recurso en cuestión. Observe que esta cabecera es similar al [HTTP/1.1 Allow: encabezado de respuesta](http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.7), pero usado estrictamente dentro del contexto del control de acceso. El servidor también envía `Access-Control-Allow-Headers` con un valor de `X-PINGOTHER`, confirmando que es una cabecera permitida para ser usado en la solicitud real. Como `Access-Control-Allow-Methods`, `Access-Control-Allow-Headers` es una lista separada por comas de cabeceras aceptables. Finalmente, `Access-Control-Max-Age` da el valor en segundos de cuánto tarda la respuesta de la solicitud verificada en ser capturada sin enviar otra solicitud verificada. En este caso, 1728000 segundos son 20 días.
+
+### Solicitudes con credenciales
+
+La capacidad más interesante expuesta tanto por [`XMLHttpRequest`](/en/DOM/XMLHttpRequest) y Access Control es la habilidad para hacer solicitudes "con credenciales" que estén al tanto de Cookies HTTP e información de Autenticación HTTP. Por defecto, en las invocaciones [`XMLHttpRequest`](/en/DOM/XMLHttpRequest) de un sitio curzado, los exploradores no enviarán credenciales. Una bandera específica tiene que ser establecida en el objeto [`XMLHttpRequest`](/en/DOM/XMLHttpRequest) cuando este es invocado.
+
+En este ejemplo, el contenido cargado originalmente desde `http://foo.example` hace una solicitud GET simple a un recurso en `http://bar.other` que establece Cookies. El contenido en foo.example puede contener un JavaScript como este:
+
+```js
+var invocation = new XMLHttpRequest();
+var url = 'http://bar.other/resources/credentialed-content/';
+
+function callOtherDomain(){
+ if(invocation) {
+ invocation.open('GET', url, true);
+ invocation.withCredentials = true;
+ invocation.onreadystatechange = handler;
+ invocation.send();
+ }
+}
+```
+
+La línea 7 muestra la bandera en [`XMLHttpRequest`](/en/DOM/XMLHttpRequest) que tiene que ser establecida para poder hacer la invocación con Cookies, es decir, el valor booleano `withCredentials`. Por defecto, la invocación es hecha sin Cookies. Dado que esta es una simple solicitud `GET`, no es verificada, pero el explorador **rechazará** cualquier respuesta que no tiene el encabezado `Access-Control-Allow-Credentials: true`,y **no** hará disponible la respuesta para invocar contenido web.
+
+A continuación se proporciona una muestra de intercambio entre un cliente y un servidor:
+
+```shell
+GET /resources/access-control-with-credentials/ HTTP/1.1
+Host: bar.other
+User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
+Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
+Accept-Language: en-us,en;q=0.5
+Accept-Encoding: gzip,deflate
+Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
+Connection: keep-alive
+Referer: http://foo.example/examples/credential.html
+Origin: http://foo.example
+Cookie: pageAccess=2
+
+
+HTTP/1.1 200 OK
+Date: Mon, 01 Dec 2008 01:34:52 GMT
+Server: Apache/2.0.61 (Unix) PHP/4.4.7 mod_ssl/2.0.61 OpenSSL/0.9.7e mod_fastcgi/2.4.2 DAV/2 SVN/1.4.2
+X-Powered-By: PHP/5.2.6
+Access-Control-Allow-Origin: http://foo.example
+Access-Control-Allow-Credentials: true
+Cache-Control: no-cache
+Pragma: no-cache
+Set-Cookie: pageAccess=3; expires=Wed, 31-Dec-2008 01:34:53 GMT
+Vary: Accept-Encoding, Origin
+Content-Encoding: gzip
+Content-Length: 106
+Keep-Alive: timeout=2, max=100
+Connection: Keep-Alive
+Content-Type: text/plain
+
+
+[text/plain payload]
+```
+
+Pese a que la línea 11 contiene la Cookie destinada para el contenido en `http://bar.other`, si bar.other no responde con `Access-Control-Allow-Credentials: true` (línea 19) la respuesta será ignorada y no puesta a disposición para el contenido web. **Nota Importante:** cuando se responde a una solicitud con credeciales, el servidor **debe\*\*** \*_especificar un dominio, y no puede usar comodines. El ejemplo de arriba fallará si la cabecera fuera un comodín como: `Access-Control-Allow-Origin: _`. Dado que `Access-Control-Allow-Origin`menciona explícitamente`http://foo.example`, el contenido de credenciales competente es devuelto al contenido web invocador. Observe que, en la línea 22, se establece una cookie adicional.
+
+Todos estos ejemplos pueden [verse funcionando aquí](http://arunranga.com/examples/access-control/). La siguiente sección se refiere a las verdaderas cabeceras HTTP.
+
+## Las cabeceras HTTP de respuesta
+
+Esta sección lista las cabeceras HTTP de respuesta que los servidores envían de vuelta para las solicitudes de acceso de control definidas por la especificación del Intercambio de Recursos de Origen Cruzado. La sección anterior da un resumen de estos en acción.
+
+### Access-Control-Allow-Origin
+
+Un recurso devuelto puede tener una cabecera `Access-Control-Allow-Origin`, con la siguiente sintaxis:
+
+```
+Access-Control-Allow-Origin: | *
+```
+
+El parámetro `origin` específica una URI que puede tener acceso al recurso. El explorador debe asegurar esto. Para solicitudes **sin** credenciales, el servidor debe especificar "\*" como un comodín permitiendo, de este modo, el acceso al recurso a cualquier origen.
+
+Por ejemplo, para permitir a http\://mozilla.com acceder al recurso, usted puede especificar:
+
+```
+Access-Control-Allow-Origin: http://mozilla.com
+```
+
+Si el servidor especifica un host de origen en vez de "\*", entonces se debe incluir Origin en el encabezado de respuesta Vary para indicar a los clientes que las respuestas del servidor difieren basándose en el valor del encabezado de respuesta Origin.
+
+### Access-Control-Expose-Headers
+
+Esta cabecera permite una _whitelist_ de cabeceras del servidor que los exploradores tienen permitido acceder. Por ejemplo:
+
+```
+Access-Control-Expose-Headers: X-My-Custom-Header, X-Another-Custom-Header
+```
+
+Esto permite a las cabeceras `X-My-Custom-Header` y`X-Another-Custom-Header` ser expuestos al explorador.
+
+### Access-Control-Max-Age
+
+Esta cabecera indica durante cuánto tiempo los resultados de la solicitud verificada pueden ser capturados. Para un ejemplo de solicitudes verificadas, vea los ejemplos de arriba.
+
+```
+Access-Control-Max-Age:
+```
+
+El parámetro `delta-seconds` indica el número de segundos en que los resultados pueden ser capturados.
+
+### Access-Control-Allow-Credentials
+
+Indica si la respuesta puede ser expuesta cuando la bandera `credentials` es verdadera. Cuando se usa como parte de una respuesta para una solicitud verficada, este indica si la solicitud verdadera puede realizarse usando credenciales. Note que las solicitudes `GET` simples no son verificadas, y por lo que si una solicitud es hecha para un recurso con credenciales, si la cabecera no es devuelta con el recurso, la respuesta es ignorada por el explorador y no devuelta al contenido web.
+
+```
+Access-Control-Allow-Credentials: true | false
+```
+
+[Las Solicitudes con credenciales](/En/HTTP_access_control#Requests_with_credentials) son discutidas arriba.
+
+### Access-Control-Allow-Methods
+
+Específica el método o los métodos permitidos cuando se asigna un recurso. Es usado en respuesta a la solicitud verificada. Las condiciones sobre cuándo una solicitud es verificada se discuten arriba.
+
+```
+Access-Control-Allow-Methods: [, ]*
+```
+
+Un ejemplo de una [solicitud verificada se muestra arriba](#Preflighted_requests), incluyendo un ejemplo donde se envía este encabezado al explorador.
+
+### Access-Control-Allow-Headers
+
+Usado en respuesta a una [solicitud verificada](#Preflighted_requests) para indicar qué encabezado HTTP puede ser usado cuando se realiza la solicitud real.
+
+```
+Access-Control-Allow-Headers: [, ]*
+```
+
+## Los encabezados HTTP de solicitud
+
+Esta sección lista las cabeceras que los clietnes deben utilizar cuando realizan solicitudes HTTP para usar la característica de intercambio de origen cruzado. Note que estas cabeceras son establecidas cuando se realizan realizan invocaciones a los servidores. Los desarrolladores usan la capacidad de sitios cruzados [`XMLHttpRequest`](/en/DOM/XMLHttpRequest) para no tener que establecer ninguna solicitud de intercambio de origen cruzado programada.
+
+### Origin
+
+Indica el origen de las solicitudes de acceso a sitios cruzados o solicitudes verificadas.
+
+```
+Origin:
+```
+
+El origen es una URI indicando al servidor dónde se ha iniciado la solicitud. Este no incluye ninguna información de recorrido, sólo el nombre del servidor.
+
+> **Nota:** El `origin` puede ser un string vacío; esto es útil, por ejemplo, si el recurso es un `data` URL.
+
+Observe que en cualquier solicitud de acceso de control, la cabecera `ORIGIN` **siempre** se envía.
+
+### Access-Control-Request-Method
+
+Se usa cuando se emite una solicitud verificada, para indicarle al servidor qué método HTTP será usado cuando se haga la solicitud real.
+
+```
+Access-Control-Request-Method:
+```
+
+Ejemplos de esta utilización pueden ser encontrados [arriba.](#Preflighted_requests)
+
+### Access-Control-Request-Headers
+
+Usada cuando se emite una solicitud verificada para indicarle al servidor qué cabecera HTTP será usada cuando se haga la solicitud real.
+
+```
+Access-Control-Request-Headers: [, ]*
+```
+
+Ejemplos de esta utilización pueden ser encontrados [arriba](/En/HTTP_access_control#Preflighted_requests).
+
+## Especificaciones
+
+| Especificación | Estado | Comentario |
+| ---------------------------------------------------------------- | ------------------------ | ----------------------------------------------------------------------- |
+| {{SpecName('Fetch', '#cors-protocol', 'CORS')}} | {{Spec2('Fetch')}} | Nueva definición; tiene como objetivo suplantar la especificación CORS. |
+| {{SpecName('CORS')}} | {{Spec2('CORS')}} | Definición inicial. |
+
+## Compatibilidad con Exploradores
+
+{{Compat("http.headers.Access-Control-Allow-Origin")}}
+
+## Vea también
+
+- [Muestras de Código mostrando `XMLHttpRequest` e Intercambio de Recursos de Origen Cruzado](http://arunranga.com/examples/access-control/)
+- [Intercambio de Recursos de Origen Cruzado desde una perspectiva de Servidor (PHP, etc.)](/es/docs/Web/HTTP/Server-Side_Access_Control)
+- [Especificación del Intercambio de Recursos de Origen Cruzado](http://www.w3.org/TR/cors/)
+- [`XMLHttpRequest`](/en/DOM/XMLHttpRequest)
+- [Discusión adicional sobre el encabezado Origin](http://crypto.stanford.edu/websec/specs/origin-header/)
+- [Usando CORS con todos los exploradores (modernos).](http://www.kendoui.com/blogs/teamblog/posts/11-10-03/using_cors_with_all_modern_browsers.aspx)
+- [Usando CORS - HTML5 Rocks](http://www.html5rocks.com/en/tutorials/cors/)
diff --git a/files/es/web/http/csp/index.html b/files/es/web/http/csp/index.html
deleted file mode 100644
index fcd294933dce85..00000000000000
--- a/files/es/web/http/csp/index.html
+++ /dev/null
@@ -1,198 +0,0 @@
----
-title: Content Security Policy (CSP)
-slug: Web/HTTP/CSP
-tags:
- - Política de Seguridad del Contenido
-translation_of: Web/HTTP/CSP
----
-
{{HTTPSidebar}}
-
-
Política de Seguridad del Contenido o( {{Glossary("CSP")}} ) - del inglés Content Security Policy - es una capa de seguridad adicional que ayuda a prevenir y mitigar algunos tipos de ataque, incluyendo Cross Site Scripting ( {{Glossary("XSS")}} ) y ataques de inyección de datos. Estos ataques son usados con diversos propósitos, desde robar información hasta desfiguración de sitios o distribución de malware .
-
-
CSP está diseñado para ser completamente retrocompatible (excepto la versión 2 de CSP, donde hay algunas menciones explícitas de inconsistencia en la retrocompatibilidad; más detalles aquí sección 1.1). Los navegadores que no lo soportan siguen funcionando con los servidores que lo implementan y viceversa: los navegadores que no soportan CSP simplemente lo ignoran, funcionando como siempre y delegando a la política mismo-origen para contenido web. Si el sitio web no ofrece la cabecera CSP, los navegadores igualmente usan la política estándar mismo-origen.
-
-
Para habilitar CSP, necesitas configurar tu servidor web para que devuelva la cabecera HTTP {{HTTPHeader("Content-Security-Policy")}} (en ocasiones verás menciones de la cabecera X-Content-Security-Policy, pero se trata de una versión antigua y no necesitas especificarla más).
-
-
Alternativamente, el elemento {{HTMLElement("meta")}} puede ser usado para configurar una política, por ejemplo: <meta http-equiv="Content-Security-Policy" content="default-src 'self'; img-src https://*; child-src 'none';">
-
-
Amenazas
-
-
Mitigando el cross site scripting
-
-
El principal objetivo del CSP es mitigar y reportar ataques XSS. Los ataques XSS se aprovechan de la confianza del navegador en el contenido que recibe del servidor. El navegador de la víctima ejecutará los scripts maliciosos porque confía en la fuente del contenido, aun cuando dicho contenido no provenga de donde se supone.
-
-
CSP hace posible que los administradores de servidores reduzcan o eliminen las posibilidades de ocurrencia de XSS mediante la especificación de dominios que el navegador considerará como fuentes válidas de scripts ejecutables. Un navegador compatible con CSP solo ejecutará scripts de los archivos fuentes especificados en esa lista blanca de dominios, ignorando completamente cualquier otro script (incluyendo los scripts inline y los atributos de HTML de manejo de eventos).
-
-
Como medida extrema de protección, los sitios que nunca requieran ejecutar scripts, pueden optar por rechazar globalmente la ejecución de scripts.
-
-
Mitigando los ataques de análisis de paquetes (packet sniffing attacks)
-
-
Además de restringir los dominios desde los cuales se puede cargar el contenido, el servidor puede especificar qué protocolos se pueden usar;por ejemplo (e idealmente, desde un punto de vista de seguridad), un servidor puede especificar que todo el contenido debe cargarse utilizando HTTPS.Una estrategia completa de seguridad en la transmisión de datos incluye no solo aplicar HTTPS para la transferencia de datos, sino también marcar todas las cookies con el indicador de seguridad y proporcionar redirecciones automáticas desde las páginas HTTP a sus homólogas HTTPS.Los sitios también pueden usar la cabecera HTTP {{HTTPHeader ("Strict-Transport-Security")}} para garantizar que los navegadores se conecten a ellos solo a través de un canal cifrado.
-
-
Utilizando CSP
-
-
La configuración de la Política de Seguridad del Contenido (CSP), consiste en agregar a una página web la cabecera HTTP {{HTTPHeader("Content-Security-Policy")}}, y darle valores para controlar los recursos que el agente de usuario puede cargar para esa página.Por ejemplo, una página que carga y muestra imágenes podría permitir imágenes desde cualquier lugar, pero pudiera restringir una acción de formulario a una ruta específica.Una Política de Seguridad de Contenido adecuadamente diseñada ayuda a proteger una página contra un ataque de scripts entre sitios.Este artículo explica cómo construir dichas cabeceras correctamente y proporciona ejemplos.
-
-
Especificando una política
-
-
Para especificar una política, se puede utilizar la cabecera HTTP {{HTTPHeader("Content-Security-Policy")}} de la siguiente manera:
-
-
Content-Security-Policy: política
-
-
La política es una cadena de caracteres que contiene las directivas que describen una determinada Política de Seguridad de Contenido.
-
-
Describiendo una política
-
-
Una política se describe utilizando una serie de directivas de políticas, cada una de las cuales describe la política para un determinado tipo de recurso o área de política.Una política debe incluir una directiva de políticas {{CSP ("default-src")}}, que es una alternativa para otros tipos de recursos cuando no tienen políticas propias (para obtener una lista completa, consulte la descripción de la directiva {{CSP("default-src")}} ).Una política debe incluir una directiva {{CSP ("default-src")}} o {{CSP ("script-src")}} para evitar la ejecución de scripts en línea, así como bloquear el uso de eval().Una política debe incluir una directiva {{CSP ("default-src")}} o {{CSP ("style-src")}} para restringir la aplicación de estilos en línea desde un elemento {{HTMLElement ("style")}}} o un atributo style.
-
-
Ejemplos: Casos de usos frecuentes
-
-
Esta sección proporciona ejemplos de algunos escenarios frecuentes de políticas de seguridad.
-
-
Ejemplo 1
-
-
Un administrador del sitio web desea que todo el contenido provenga del mismo origen que el del sitio (esto excluye subdominios).
-
-
Content-Security-Policy: default-src 'self'
-
-
Ejemplo 2
-
-
El administrador de un sitio web desea permitir el contenido de un dominio de confianza y todos sus subdominios (no tiene que ser el mismo dominio en el que está configurado el CSP).
El administrador de un sitio web desea permitir que los usuarios de una aplicación web incluyan imágenes de cualquier origen en su propio contenido, pero restringen los medios de audio o video a proveedores de confianza, y todas las secuencias de comandos solo a un servidor específico que aloja un código de confianza.
Aquí, de forma predeterminada, el contenido solo se permite desde el origen del documento, con las siguientes excepciones:
-
-
-
Las imágenes pueden cargarse desde cualquier lugar (tenga en cuenta el comodín "*").
-
Los archivos de medios solo están permitidos desde media1.com y media2.com (y no desde los subdominios de esos sitios).
-
El script ejecutable solo está permitido desde userscripts.example.com.
-
-
-
Ejemplo 4
-
-
En administrador de un sitio web de banca en línea quiere asegurarse de que todo su contenido se cargue mediante SSL, para evitar que los atacantes puedan espiar las solicitudes.
El servidor solo permite el acceso a documentos que se cargan específicamente a través de HTTPS a través del único origen onlinebanking.jumbobank.com.
-
-
Ejemplo 5
-
-
El administrador de un sitio de correo web desea permitir HTML en el correo electrónico, así como imágenes cargadas desde cualquier lugar, pero no JavaScript u otro contenido potencialmente peligroso.
Tenga en cuenta que este ejemplo no especifica un {{CSP ("script-src")}} ;con el CSP de ejemplo, este sitio utiliza la configuración especificada por la directiva {{CSP ("default-src")}} , lo que significa que los scripts solo se pueden cargar desde el servidor de origen.
-
-
Comprobando una política
-
-
Para facilitar la implementación, CSP se puede implementar en modo de solo informe.La política no se aplica, pero cualquier violación se informa a un URI proporcionado.Además, se puede usar una cabecera de solo informe para probar una futura revisión de una política sin implementarla realmente.
-
- Se puede usar la cabecera HTTP {{HTTPHeader ("Content-Security-Policy-Report-Only")}} para especificar una política de la siguiente manera:
-
-
Content-Security-Policy-Report-Only: policy
-
-
Si la cabecera {{HTTPHeader ("Content-Security-Policy-Report-Only")}} y la cabecera {{HTTPHeader ("Content-Security-Policy")}} están presentes en la misma respuesta, ambas políticas se cumplen.La política especificada en la cabecera Content-Security-Policy se aplica, mientras que la política Content-Security-Policy-Report-Only genera informes pero no se aplica.
-
-
Habilitación de informes
-
-
Por defecto, los informes de violación no son enviados.Para habilitar los informes de violación, debe especificar la directiva de políticas {{CSP ("report-uri")}} , proporcionando al menos un URI al que entregar los informes:
Luego se debe configurar el servidor para recibir los informes;se pueden almacenar o procesar de la manera que considere apropiada.
-
-
Sintáxis del informe de violación
-
-
El informe es un objeto JSON que contiene los datos siguientes:
-
-
-
blocked-uri
-
El URI del recurso bloqueado por la Política de Seguridad de Contenido.Si el URI bloqueado es de un origen diferente al del document-uri, el URI bloqueado se trunca para contener solo el esquema, el host y el puerto.
-
-
-
-
disposition
-
Toma el valor "enforce" o "reporting" dependiendo de si se utiliza la cabecera {{HTTPHeader("Content-Security-Policy-Report-Only")}} o Content-Security-Policy.
-
document-uri
-
El URI del documento donde ocurrió la violación.
-
effective-directive
-
La directiva cuya aplicación causó la violación.
-
original-policy
-
La política original especificada por la cabecera HTTP Content-Security-Policy.
-
referrer
-
El referente del documento en el que ocurrió la violación.
-
script-sample
-
Los primeros 40 caracteres del script inline, el controlador de eventos o el estilo que causó la violación.
-
status-code
-
El código de estado HTTP del recurso en el que se creó una instancia del objeto global.
-
violated-directive
-
El nombre de la sección de política que fue violada.
-
-
-
Ejemplo de informe de violación
-
-
Consideremos una página ubicada en http://example.com/signup.html que tiene las siguiente política: rechazar todo, excepto las hojas de estilo provenientes de cdn.example.com.
¿Puedes ver el error? Las hojas de estilo solo se pueden cargar desde cdn.example.com, pero el sitio web intenta cargar una desde su propio origen (http://example.com).Un navegador capaz de aplicar el CSP enviará el siguiente informe de violación mediante una solicitud POST a http://example.com/_/csp-reports, cuando se visite el documento:
Como se puede ver, el informe incluye la ruta completa al recurso infractor en blocked-uri.Este no es siempre el caso.Por ejemplo, cuando signup.html intente cargar el CSS desde http://anothercdn.example.com/stylesheet.css, el navegador no incluiría la ruta completa, sino solo el origen (http://anothercdn.example.com).La especificación CSP da una explicación de este extraño comportamiento.En resumen, esto se hace para evitar la pérdida de información confidencial sobre recursos de origen cruzado.
-
-
Compatibilidad del navegador
-
-
-
-
{{Compat("http.headers.csp")}}
-
-
Existe una incompatibilidad específica en algunas versiones del navegador web Safari, por lo que si se establece una cabecera de Política de Seguridad de Contenido, pero no una cabecera de Same Origin, el navegador bloqueará el contenido alojado de forma autónoma y el contenido externo, e informará incorrectamente de que esto es debido a que la Política de Seguridad del Contenido no permite el contenido.
diff --git a/files/es/web/http/csp/index.md b/files/es/web/http/csp/index.md
new file mode 100644
index 00000000000000..170e73ae2e9ad6
--- /dev/null
+++ b/files/es/web/http/csp/index.md
@@ -0,0 +1,202 @@
+---
+title: Content Security Policy (CSP)
+slug: Web/HTTP/CSP
+tags:
+ - Política de Seguridad del Contenido
+translation_of: Web/HTTP/CSP
+---
+{{HTTPSidebar}}
+
+**Política de Seguridad del Contenido** o ( {{Glossary("CSP")}} ) - del inglés ***Content Security Policy*** - es una capa de seguridad adicional que ayuda a prevenir y mitigar algunos tipos de ataque, incluyendo Cross Site Scripting ( {{Glossary("XSS")}} ) y ataques de inyección de datos. Estos ataques son usados con diversos propósitos, desde robar información hasta desfiguración de sitios o distribución de malware .
+
+CSP está diseñado para ser completamente retrocompatible (excepto la versión 2 de CSP, donde hay algunas menciones explícitas de inconsistencia en la retrocompatibilidad; más detalles [aquí](https://www.w3.org/TR/CSP2) sección 1.1). Los navegadores que no lo soportan siguen funcionando con los servidores que lo implementan y viceversa: los navegadores que no soportan CSP simplemente lo ignoran, funcionando como siempre y delegando a la política mismo-origen para contenido web. Si el sitio web no ofrece la cabecera CSP, los navegadores igualmente usan la política estándar [mismo-origen](/es/docs/Web/Security/Same-origin_policy).
+
+Para habilitar CSP, necesitas configurar tu servidor web para que devuelva la cabecera HTTP {{HTTPHeader("Content-Security-Policy")}} (en ocasiones verás menciones de la cabecera `X-Content-Security-Policy`, pero se trata de una versión antigua y no necesitas especificarla más).
+
+Alternativamente, el elemento {{HTMLElement("meta")}} puede ser usado para configurar una política, por ejemplo: ``
+
+## Amenazas
+
+### Mitigando el cross site scripting
+
+El principal objetivo del CSP es mitigar y reportar ataques XSS. Los ataques XSS se aprovechan de la confianza del navegador en el contenido que recibe del servidor. El navegador de la víctima ejecutará los scripts maliciosos porque confía en la fuente del contenido, aun cuando dicho contenido no provenga de donde se supone.
+
+CSP hace posible que los administradores de servidores reduzcan o eliminen las posibilidades de ocurrencia de XSS mediante la especificación de dominios que el navegador considerará como fuentes válidas de scripts ejecutables. Un navegador compatible con CSP solo ejecutará scripts de los archivos fuentes especificados en esa lista blanca de dominios, ignorando completamente cualquier otro script (incluyendo los scripts inline y los atributos de HTML de manejo de eventos).
+
+Como medida extrema de protección, los sitios que nunca requieran ejecutar scripts, pueden optar por rechazar globalmente la ejecución de scripts.
+
+### Mitigando los ataques de análisis de paquetes _(packet sniffing attacks)_
+
+Además de restringir los dominios desde los cuales se puede cargar el contenido, el servidor puede especificar qué protocolos se pueden usar; por ejemplo (e idealmente, desde un punto de vista de seguridad), un servidor puede especificar que todo el contenido debe cargarse utilizando HTTPS. Una estrategia completa de seguridad en la transmisión de datos incluye no solo aplicar HTTPS para la transferencia de datos, sino también marcar todas las cookies con el indicador de seguridad y proporcionar redirecciones automáticas desde las páginas HTTP a sus homólogas HTTPS. Los sitios también pueden usar la cabecera HTTP {{HTTPHeader ("Strict-Transport-Security")}} para garantizar que los navegadores se conecten a ellos solo a través de un canal cifrado.
+
+## Utilizando CSP
+
+La configuración de la Política de Seguridad del Contenido (CSP), consiste en agregar a una página web la cabecera HTTP {{HTTPHeader("Content-Security-Policy")}}, y darle valores para controlar los recursos que el agente de usuario puede cargar para esa página. Por ejemplo, una página que carga y muestra imágenes podría permitir imágenes desde cualquier lugar, pero pudiera restringir una acción de formulario a una ruta específica. Una Política de Seguridad de Contenido adecuadamente diseñada ayuda a proteger una página contra un ataque de scripts entre sitios. Este artículo explica cómo construir dichas cabeceras correctamente y proporciona ejemplos.
+
+### Especificando una política
+
+Para especificar una política, se puede utilizar la cabecera HTTP {{HTTPHeader("Content-Security-Policy")}} de la siguiente manera:
+
+```
+Content-Security-Policy: política
+```
+
+La _política_ es una cadena de caracteres que contiene las directivas que describen una determinada Política de Seguridad de Contenido.
+
+### Describiendo una política
+
+Una política se describe utilizando una serie de directivas de políticas, cada una de las cuales describe la política para un determinado tipo de recurso o área de política. Una política debe incluir una directiva de políticas {{CSP ("default-src")}}, que es una alternativa para otros tipos de recursos cuando no tienen políticas propias (para obtener una lista completa, consulte la descripción de la directiva {{CSP("default-src")}} ). Una política debe incluir una directiva {{CSP ("default-src")}} o {{CSP ("script-src")}} para evitar la ejecución de scripts en línea, así como bloquear el uso de `eval()`. Una política debe incluir una directiva {{CSP ("default-src")}} o {{CSP ("style-src")}} para restringir la aplicación de estilos en línea desde un elemento {{HTMLElement ("style")}}} o un atributo `style`.
+
+## Ejemplos: Casos de usos frecuentes
+
+Esta sección proporciona ejemplos de algunos escenarios frecuentes de políticas de seguridad.
+
+### Ejemplo 1
+
+Un administrador del sitio web desea que todo el contenido provenga del mismo origen que el del sitio (esto excluye subdominios).
+
+```
+Content-Security-Policy: default-src 'self'
+```
+
+### Ejemplo 2
+
+El administrador de un sitio web desea permitir el contenido de un dominio de confianza y todos sus subdominios (no tiene que ser el mismo dominio en el que está configurado el CSP).
+
+```
+Content-Security-Policy: default-src 'self' *.trusted.com
+```
+
+### Ejemplo 3
+
+El administrador de un sitio web desea permitir que los usuarios de una aplicación web incluyan imágenes de cualquier origen en su propio contenido, pero restringen los medios de audio o video a proveedores de confianza, y todas las secuencias de comandos solo a un servidor específico que aloja un código de confianza.
+
+```
+Content-Security-Policy: default-src 'self'; img-src *; media-src media1.com media2.com; script-src userscripts.example.com
+```
+
+Aquí, de forma predeterminada, el contenido solo se permite desde el origen del documento, con las siguientes excepciones:
+
+- Las imágenes pueden cargarse desde cualquier lugar (tenga en cuenta el comodín "\*").
+- Los archivos de medios solo están permitidos desde media1.com y media2.com (y no desde los subdominios de esos sitios).
+- El script ejecutable solo está permitido desde userscripts.example.com.
+
+### Ejemplo 4
+
+En administrador de un sitio web de banca en línea quiere asegurarse de que todo su contenido se cargue mediante SSL, para evitar que los atacantes puedan espiar las solicitudes.
+
+```
+Content-Security-Policy: default-src https://onlinebanking.jumbobank.com
+```
+
+El servidor solo permite el acceso a documentos que se cargan específicamente a través de HTTPS a través del único origen onlinebanking.jumbobank.com.
+
+### Ejemplo 5
+
+El administrador de un sitio de correo web desea permitir HTML en el correo electrónico, así como imágenes cargadas desde cualquier lugar, pero no JavaScript u otro contenido potencialmente peligroso.
+
+```
+Content-Security-Policy: default-src 'self' *.mailsite.com; img-src *
+```
+
+Tenga en cuenta que este ejemplo no especifica un {{CSP ("script-src")}} ; con el CSP de ejemplo, este sitio utiliza la configuración especificada por la directiva {{CSP ("default-src")}} , lo que significa que los scripts solo se pueden cargar desde el servidor de origen.
+
+## Comprobando una política
+
+Para facilitar la implementación, CSP se puede implementar en modo de solo informe. La política no se aplica, pero cualquier violación se informa a un URI proporcionado. Además, se puede usar una cabecera de solo informe para probar una futura revisión de una política sin implementarla realmente.
+
+Se puede usar la cabecera HTTP {{HTTPHeader ("Content-Security-Policy-Report-Only")}} para especificar una política de la siguiente manera:
+
+```
+Content-Security-Policy-Report-Only: policy
+```
+
+Si la cabecera {{HTTPHeader ("Content-Security-Policy-Report-Only")}} y la cabecera {{HTTPHeader ("Content-Security-Policy")}} están presentes en la misma respuesta, ambas políticas se cumplen. La política especificada en la cabecera `Content-Security-Policy` se aplica, mientras que la política `Content-Security-Policy-Report-Only` genera informes pero no se aplica.
+
+## Habilitación de informes
+
+Por defecto, los informes de violación no son enviados. Para habilitar los informes de violación, debe especificar la directiva de políticas {{CSP ("report-uri")}} , proporcionando al menos un URI al que entregar los informes:
+
+```
+Content-Security-Policy: default-src 'self'; report-uri http://reportcollector.example.com/collector.cgi
+```
+
+Luego se debe configurar el servidor para recibir los informes; se pueden almacenar o procesar de la manera que considere apropiada.
+
+## Sintáxis del informe de violación
+
+El informe es un objeto JSON que contiene los datos siguientes:
+
+- `blocked-uri`
+ - : El URI del recurso bloqueado por la Política de Seguridad de Contenido. Si el URI bloqueado es de un origen diferente al del **document-uri**, el URI bloqueado se trunca para contener solo el esquema, el host y el puerto.
+
+
+
+- `disposition`
+ - : Toma el valor `"enforce"` o `"reporting"` dependiendo de si se utiliza la cabecera {{HTTPHeader("Content-Security-Policy-Report-Only")}} o `Content-Security-Policy`.
+- `document-uri`
+ - : El URI del documento donde ocurrió la violación.
+- `effective-directive`
+ - : La directiva cuya aplicación causó la violación.
+- `original-policy`
+ - : La política original especificada por la cabecera HTTP `Content-Security-Policy`.
+- `referrer`
+ - : El referente del documento en el que ocurrió la violación.
+- `script-sample`
+ - : Los primeros 40 caracteres del script inline, el controlador de eventos o el estilo que causó la violación.
+- `status-code`
+ - : El código de estado HTTP del recurso en el que se creó una instancia del objeto global.
+- `violated-directive`
+ - : El nombre de la sección de política que fue violada.
+
+## Ejemplo de informe de violación
+
+Consideremos una página ubicada en que tiene las siguiente política: rechazar todo, excepto las hojas de estilo provenientes de .
+
+```
+Content-Security-Policy: default-src 'none'; style-src cdn.example.com; report-uri /_/csp-reports
+```
+
+El código HTML de `signup.html` es el siguiente:
+
+```html
+
+
+
+ Sign Up
+
+
+
+ ... Content ...
+
+
+```
+
+¿Puedes ver el error? Las hojas de estilo solo se pueden cargar desde , pero el sitio web intenta cargar una desde su propio origen (). Un navegador capaz de aplicar el CSP enviará el siguiente informe de violación mediante una solicitud POST a , cuando se visite el documento:
+
+```
+{
+ "csp-report": {
+ "document-uri": "http://example.com/signup.html",
+ "referrer": "",
+ "blocked-uri": "http://example.com/css/style.css",
+ "violated-directive": "style-src cdn.example.com",
+ "original-policy": "default-src 'none'; style-src cdn.example.com; report-uri /_/csp-reports"
+ }
+}
+```
+
+Como se puede ver, el informe incluye la ruta completa al recurso infractor en `blocked-uri`. Este no es siempre el caso. Por ejemplo, cuando `signup.html` intente cargar el CSS desde , el navegador no incluiría la ruta completa, sino solo el origen (). La especificación CSP da una explicación de este extraño comportamiento. En resumen, esto se hace para evitar la pérdida de información confidencial sobre recursos de origen cruzado.
+
+## Compatibilidad del navegador
+
+{{Compat("http.headers.csp")}}
+
+Existe una incompatibilidad específica en algunas versiones del navegador web Safari, por lo que si se establece una cabecera de Política de Seguridad de Contenido, pero no una cabecera de Same Origin, el navegador bloqueará el contenido alojado de forma autónoma y el contenido externo, e informará incorrectamente de que esto es debido a que la Política de Seguridad del Contenido no permite el contenido.
+
+## Vea también
+
+- {{HTTPHeader("Content-Security-Policy")}}
+- {{HTTPHeader("Content-Security-Policy-Report-Only")}}
+- [Content Security in WebExtensions](/es/docs/Mozilla/Add-ons/WebExtensions/Content_Security_Policy)
+- [Display security and privacy policies In Firefox Developer Tools](/es/docs/Tools/GCLI/Display_security_and_privacy_policies)
diff --git a/files/es/web/http/headers/accept/index.html b/files/es/web/http/headers/accept/index.html
deleted file mode 100644
index ec9ff6f60a0ba4..00000000000000
--- a/files/es/web/http/headers/accept/index.html
+++ /dev/null
@@ -1,99 +0,0 @@
----
-title: Accept
-slug: Web/HTTP/Headers/Accept
-tags:
- - Cabecera HTTP
- - Cabecera de Pedido
- - HTTP
- - Referencia
-translation_of: Web/HTTP/Headers/Accept
----
-
{{HTTPSidebar}}
-
-
La cabecera de pedido Accept anuncia que tipo de contenido el cliente puede procesar, expresado como un tipo MIME. Usando negociación de contenido, el servidor selecciona una de las propuestas , la utiliza e informa al cliente de la elección a través de la cabecera de respuesta {{HTTPHeader("Content-Type")}} .
-
-
Los navegadores configuran los valores adecuados en dependencia del contexto donde se ha hecho el pedido, por ejemplo: al solicitar una hoja de estilos CSS es configurado un valor diferente que cuando se solicita una imagen, un video o un script.
Cabecera con el resultado de la negociación de contenido: {{HTTPHeader("Content-Type")}}
-
Otras cabeceras similares: {{HTTPHeader("TE")}}, {{HTTPHeader("Accept-Encoding")}}, {{HTTPHeader("Accept-Charset")}}, {{HTTPHeader("Accept-Language")}}
-
diff --git a/files/es/web/http/headers/accept/index.md b/files/es/web/http/headers/accept/index.md
new file mode 100644
index 00000000000000..aea674a11c63f9
--- /dev/null
+++ b/files/es/web/http/headers/accept/index.md
@@ -0,0 +1,89 @@
+---
+title: Accept
+slug: Web/HTTP/Headers/Accept
+tags:
+ - Cabecera HTTP
+ - Cabecera de Pedido
+ - HTTP
+ - Referencia
+translation_of: Web/HTTP/Headers/Accept
+---
+{{HTTPSidebar}}
+
+`La cabecera de pedido Accept` anuncia que tipo de contenido el cliente puede procesar, expresado como un tipo [MIME](/es/docs/Web/HTTP/Basics_of_HTTP/MIME_types). Usando [negociación de contenido](/es/docs/Web/HTTP/Content_negotiation), el servidor selecciona una de las propuestas , la utiliza e informa al cliente de la elección a través de la cabecera de respuesta {{HTTPHeader("Content-Type")}} .
+
+Los navegadores configuran los valores adecuados en dependencia del contexto donde se ha hecho el pedido, por ejemplo: al solicitar una hoja de estilos CSS es configurado un valor diferente que cuando se solicita una imagen, un video o un script.
+
+
+
+## Sintaxis
+
+```
+Accept: /
+Accept: /*
+Accept: */*
+
+// Multiples tipos, priorizados con {{glossary("quality values", "quality value")}} sintaxis:
+Accept: text/html, application/xhtml+xml, application/xml;q=0.9, */*;q=0.8
+```
+
+## Directivas
+
+- `/`
+ - : Un único y preciso tipo [MIME](/es/docs/Web/HTTP/Basics_of_HTTP/MIME_types), como `text/html`.
+- `/*`
+
+ - : Un tipo MIME, pero con cualquier subtipo.
+ Por ejmplo, image/\* comincide con:
+
+ - image/png
+ - image/svg
+ - image/gif
+
+- `*/*`
+ - : Culaquier tipo MIME
+- `;q=` (donde _q_ es la importancia o peso)
+ - : Culaquier valor es colocado en orden de preferencia, expresada usando un [valor de calidad](/es/docs/Glossary/Quality_values) llamado _weight_ (_peso_ en español).
+
+## Ejemplos
+
+```
+Accept: text/html
+
+Accept: image/*
+
+Accept: text/html, application/xhtml+xml, application/xml;q=0.9, */*;q=0.8
+```
+
+## Especificaciones
+
+| Especificación | Titulo |
+| -------------------------------------------- | ------------------------------------------------------------- |
+| {{RFC("7231", "Accept", "5.3.2")}} | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Context |
+
+## Compatibilidad con Navegadores
+
+{{Compat("http.headers.Accept")}}
+
+## Tambien Ver
+
+- [Negociación de Contenido HTTP](/es/docs/Web/HTTP/Content_negotiation)
+- Cabecera con el resultado de la negociación de contenido: {{HTTPHeader("Content-Type")}}
+- Otras cabeceras similares: {{HTTPHeader("TE")}}, {{HTTPHeader("Accept-Encoding")}}, {{HTTPHeader("Accept-Charset")}}, {{HTTPHeader("Accept-Language")}}
diff --git a/files/es/web/http/headers/access-control-allow-origin/index.html b/files/es/web/http/headers/access-control-allow-origin/index.html
deleted file mode 100644
index fa6b2a872dfefd..00000000000000
--- a/files/es/web/http/headers/access-control-allow-origin/index.html
+++ /dev/null
@@ -1,99 +0,0 @@
----
-title: Access-Control-Allow-Origin
-slug: Web/HTTP/Headers/Access-Control-Allow-Origin
-tags:
- - Access Control
- - Access-Control-Allow-Origin
- - CORS
- - HTTP
- - Lidiando con CORS
- - Origen
- - Referencia
- - Seguridad
- - encabezado HTTP
- - error cross-origin
-translation_of: Web/HTTP/Headers/Access-Control-Allow-Origin
----
-
{{HTTPSidebar}}
-
-
El encabezado de respuesta Access-Control-Allow-Origin indica si los recursos de la respuesta pueden ser compartidos con el {{glossary("origin", "origen")}} dado.
-
-
-
-
-
Tipo de encabezado
-
{{Glossary("Response header", "Encabezado de respuesta")}}
-
-
-
{{Glossary("Forbidden header name", "Nombre de encabezado prohibido")}}
Para las peticiones sin credenciales, el servidor puede especificar el caracter "*" como un comodín, permitiendo a cualquier origen acceder al recurso. El acceso será permitido solamente para las peticiones hechas con el atributo {{htmlattrxref("crossorigin")}} definido como "anonymous". Intentar usar el comodín con credenciales resultará en un error.
-
-
<origen>
-
Especifica que origen puede acceder al recurso. Sólo se puede especificar un origen.
-
-
-
Ejemplos
-
-
Para permitir a cualquier origen el acceso a tus recursos, puedes especificar:
-
-
Access-Control-Allow-Origin: *
-
-
Una respuesta que le dice al navegador que permita la petición de código del origen https://developer.mozilla.org para acceder a los recursos que incluyan lo siguiente:
Limitando los posibles valores Access-Control-Allow-Origin de un conjunto de orígenes permitidos requiere código del lado del servidor para revisar el valor de la encabezado de petición {{HTTPHeader("Origin")}}, comparan con la lista de valores permitidos, y entonces si el valor {{HTTPHeader("Origin")}} se encuentra en la lista, para definir el valor de Access-Control-Allow-Origin al mismo valor que {{HTTPHeader("Origin")}}.
-
-
CORS y caché
-
-
Si el servidor envía una respuesta con un valor Access-Control-Allow-Origin que es un origen explícito (en lugar del comodín "*"), entonces a respuesta debería incluir también el encabezado de respuesta {{HTTPHeader("Vary")}} con el valor origin - para indicar a los navegadores que las respuestas del servidor pueden diferir basadas en el valor del encabezado de respueta Origin.
diff --git a/files/es/web/http/headers/access-control-allow-origin/index.md b/files/es/web/http/headers/access-control-allow-origin/index.md
new file mode 100644
index 00000000000000..4bbce6d7422bd3
--- /dev/null
+++ b/files/es/web/http/headers/access-control-allow-origin/index.md
@@ -0,0 +1,92 @@
+---
+title: Access-Control-Allow-Origin
+slug: Web/HTTP/Headers/Access-Control-Allow-Origin
+tags:
+ - Access Control
+ - Access-Control-Allow-Origin
+ - CORS
+ - HTTP
+ - Lidiando con CORS
+ - Origen
+ - Referencia
+ - Seguridad
+ - encabezado HTTP
+ - error cross-origin
+translation_of: Web/HTTP/Headers/Access-Control-Allow-Origin
+---
+{{HTTPSidebar}}
+
+El encabezado de respuesta **`Access-Control-Allow-Origin`** indica si los recursos de la respuesta pueden ser compartidos con el {{glossary("origin", "origen")}} dado.
+
+
+
+
+
Tipo de encabezado
+
+ {{Glossary("Response header", "Encabezado de respuesta")}}
+
+
+
+
+ {{Glossary("Forbidden header name", "Nombre de encabezado prohibido")}}
+
+
no
+
+
+
+
+## Sintaxis
+
+```
+Access-Control-Allow-Origin: *
+Access-Control-Allow-Origin:
+Access-Control-Allow-Origin: null
+```
+
+## Directivas
+
+- `*`
+ - : Para las peticiones _sin credenciales_, el servidor puede especificar el caracter "\*" como un comodín, permitiendo a cualquier origen acceder al recurso. El acceso será permitido solamente para las peticiones hechas con el atributo {{htmlattrxref("crossorigin")}} definido como `"anonymous"`. Intentar usar el comodín con credenciales [resultará en un error](/es/docs/Web/HTTP/CORS/Errors/CORSNotSupportingCredentials).
+- ``
+ - : Especifica que origen puede acceder al recurso. Sólo se puede especificar un origen.
+
+## Ejemplos
+
+Para permitir a cualquier origen el acceso a tus recursos, puedes especificar:
+
+```
+Access-Control-Allow-Origin: *
+```
+
+Una respuesta que le dice al navegador que permita la petición de código del origen `https://developer.mozilla.org` para acceder a los recursos que incluyan lo siguiente:
+
+```
+Access-Control-Allow-Origin: https://developer.mozilla.org
+```
+
+Limitando los posibles valores `Access-Control-Allow-Origin` de un conjunto de orígenes permitidos requiere código del lado del servidor para revisar el valor de la encabezado de petición {{HTTPHeader("Origin")}}, comparan con la lista de valores permitidos, y entonces si el valor {{HTTPHeader("Origin")}} se encuentra en la lista, para definir el valor de `Access-Control-Allow-Origin` al mismo valor que {{HTTPHeader("Origin")}}.
+
+### CORS y caché
+
+Si el servidor envía una respuesta con un valor `Access-Control-Allow-Origin` que es un origen explícito (en lugar del comodín "`*`"), entonces a respuesta debería incluir también el encabezado de respuesta {{HTTPHeader("Vary")}} con el valor `origin` - para indicar a los navegadores que las respuestas del servidor pueden diferir basadas en el valor del encabezado de respueta `Origin`.
+
+```
+Access-Control-Allow-Origin: https://developer.mozilla.org
+Vary: Origin
+```
+
+## Especificaciones
+
+| Especificación | Estado | Comentario |
+| -------------------------------------------------------------------------------------------------------------------- | ------------------------ | ------------------- |
+| {{SpecName('Fetch','#http-access-control-allow-origin', 'Access-Control-Allow-Origin')}} | {{Spec2("Fetch")}} | Definición Inicial. |
+
+## Compatibilidad del Navegador
+
+{{Compat("http.headers.Access-Control-Allow-Origin")}}
+
+## Veáse también
+
+- {{HTTPHeader("Origin")}}
+- {{HTTPHeader("Vary")}}
+- [Cross-Origin Resource Sharing (CORS)](/es/docs/Web/HTTP/CORS)
diff --git a/files/es/web/http/headers/content-security-policy/index.html b/files/es/web/http/headers/content-security-policy/index.html
deleted file mode 100644
index 46e0cb55bc17cb..00000000000000
--- a/files/es/web/http/headers/content-security-policy/index.html
+++ /dev/null
@@ -1,250 +0,0 @@
----
-title: Content-Security-Policy
-slug: Web/HTTP/Headers/Content-Security-Policy
-tags:
- - CSP
- - HTTP
- - Reference
- - header
-translation_of: Web/HTTP/Headers/Content-Security-Policy
----
-
{{HTTPSidebar}}
-
-
-
-
- La cabecera HTTP Content-Security-Policy en la respuesta permite a los administradores de un sitio web controlar los recursos que el User-Agent puede cargar a una pagina. Con algunas (Poquísimas) excepciones, las políticas implican principalmente especificar el servidor de origen la protección de puntos finales del script. Esto ayuda a protegerse contra ataques Cross-site scripting ({{Glossary("XSS")}}).
"Fetch directives" controla la ubicación o ubicaciones desde la cual se pueden cargar ciertos tipos de recursos
-
-
Lista de Content Security Policy Fetch directives
-
-
-
{{CSP("child-src")}}
-
Define los origenes válidos para web workers y contextos de navegación anidados cargados usando elementos como {{HTMLElement("frame")}} and {{HTMLElement("iframe")}}.
-
-
En lugar de child-src, los autores quienes deseen regular los contextos de navegación anidados y "workers" deberían usar las directivas {{CSP("frame-src")}} y {{CSP("worker-src")}}, respectivamente.
-
-
-
{{CSP("connect-src")}}
-
Restringe las URLs que pueden ser cargados usando scripts.
-
{{CSP("default-src")}}
-
Serves as a fallback for the other {{Glossary("Fetch directive", "fetch directives")}}.
-
{{CSP("font-src")}}
-
Especifica origenes válidos para las fuentes cargadas usando {{cssxref("@font-face")}}.
-
{{CSP("frame-src")}}
-
Especifica origenes válidos para contextos de navageción anidada cargados usando elementos como {{HTMLElement("frame")}} y {{HTMLElement("iframe")}}.
-
{{CSP("img-src")}}
-
Especifica origenes válidos de imágenes y favicons.
-
{{CSP("manifest-src")}}
-
Especifica origenes válidos de archivos de manifiesto de una aplicación.
-
{{CSP("media-src")}}
-
Especifica origenes válidos para carga de archivos usando elementos como {{HTMLElement("audio")}} , {{HTMLElement("video")}} y {{HTMLElement("track")}}.
-
{{CSP("object-src")}}
-
Specifies valid sources for the {{HTMLElement("object")}}, {{HTMLElement("embed")}}, and {{HTMLElement("applet")}} elements.
-
Elements controlled by object-src are perhaps coincidentally considered legacy HTML elements and aren't recieving new standardized features (such as the security attributes sandbox or allow for <iframe>). Therefore it is recommended to restrict this fetch-directive (e.g. explicitly set object-src 'none' if possible).
-
{{CSP("prefetch-src")}}
-
Specifies valid sources to be prefetched or prerendered.
Navigation directives govern to which location a user can navigate to or submit a form to, for example.
-
-
-
{{CSP("form-action")}}
-
Restricts the URLs which can be used as the target of a form submissions from a given context.
-
{{CSP("frame-ancestors")}}
-
Specifies valid parents that may embed a page using {{HTMLElement("frame")}}, {{HTMLElement("iframe")}}, {{HTMLElement("object")}}, {{HTMLElement("embed")}}, or {{HTMLElement("applet")}}.
-
{{CSP("navigate-to")}} {{experimental_inline}}
-
Restricts the URLs to which a document can navigate by any means (a, form, window.location, window.open, etc.)
Reporting directives control the reporting process of CSP violations. See also the {{HTTPHeader("Content-Security-Policy-Report-Only")}} header.
-
-
-
{{CSP("report-uri")}} {{obsolete_inline}}
-
Instructs the user agent to report attempts to violate the Content Security Policy. These violation reports consist of {{Glossary("JSON")}} documents sent via an HTTP POST request to the specified URI.
-
-
Though the {{CSP("report-to")}} directive is intended to replace the deprecated report-uri directive, {{CSP("report-to")}} isn’t supported in most browsers yet. So for compatibility with current browsers while also adding forward compatibility when browsers get {{CSP("report-to")}} support, you can specify both report-uri and {{CSP("report-to")}}:
In browsers that support {{CSP("report-to")}}, the report-uri directive will be ignored.
-
-
-
{{CSP("report-to")}} {{experimental_inline}}
-
Fires a SecurityPolicyViolationEvent.
-
-
-
Other directives
-
-
-
{{CSP("block-all-mixed-content")}}
-
Prevents loading any assets using HTTP when the page is loaded using HTTPS.
-
{{CSP("referrer")}} {{obsolete_inline}}
-
Used to specify information in the referer (sic) header for links away from a page. Use the {{HTTPHeader("Referrer-Policy")}} header instead.
-
{{CSP("require-sri-for")}}
-
Requires the use of {{Glossary("SRI")}} for scripts or styles on the page.
-
-
-
-
{{CSP("trusted-types")}} {{experimental_inline}}
-
Used to specify a whitelist of Trusted Types policies (Trusted Types allows applications to lock down DOM XSS injection sinks to only accept non-spoofable, typed values in place of strings).
-
-
-
-
{{CSP("upgrade-insecure-requests")}}
-
Instructs user agents to treat all of a site's insecure URLs (those served over HTTP) as though they have been replaced with secure URLs (those served over HTTPS). This directive is intended for web sites with large numbers of insecure legacy URLs that need to be rewritten.
-
-
-
CSP in workers
-
-
Workers en general no se rigen por las politicas de seguridad de contenido de el documento (o padre del worker) que los creó. To specify a content security policy for the worker, set a Content-Security-Policy response header for the request which requested the worker script itself.
-
-
The exception to this is if the worker script's origin is a globally unique identifier (for example, if its URL has a scheme of data or blob). In this case, the worker does inherit the content security policy of the document or worker that created it.
-
-
Multiple content security policies
-
-
CSP allows multiple policies being specified for a resource, including via the Content-Security-Policy header, the {{HTTPHeader("Content-Security-Policy-Report-Only")}} header and a {{HTMLElement("meta")}} element.
-
-
You can use the Content-Security-Policy header more than once like in the example below. Pay special attention to the {{CSP("connect-src")}} directive here. Even though the second policy would allow the connection, the first policy contains connect-src 'none'. Adding additional policies can only further restrict the capabilities of the protected resource, which means that there will be no connection allowed and, as the strictest policy, connect-src 'none' is enforced.
diff --git a/files/es/web/http/headers/content-security-policy/index.md b/files/es/web/http/headers/content-security-policy/index.md
new file mode 100644
index 00000000000000..4421859cf16fe3
--- /dev/null
+++ b/files/es/web/http/headers/content-security-policy/index.md
@@ -0,0 +1,208 @@
+---
+title: Content-Security-Policy
+slug: Web/HTTP/Headers/Content-Security-Policy
+tags:
+ - CSP
+ - HTTP
+ - Reference
+ - header
+translation_of: Web/HTTP/Headers/Content-Security-Policy
+---
+{{HTTPSidebar}}
+
+La cabecera HTTP **`Content-Security-Policy`** en la respuesta permite a los administradores de un sitio web controlar los recursos que el User-Agent puede cargar a una pagina. Con algunas (Poquísimas) excepciones, las políticas implican principalmente especificar el servidor de origen la protección de puntos finales del script. Esto ayuda a protegerse contra ataques Cross-site scripting ({{Glossary("XSS")}}).
+
+Para mas información, ve también este articulo en [Content Security Policy (CSP)](/es/docs/Web/HTTP/CSP).
+
+
+
+
+
Tipo de cabecera
+
{{Glossary("Response header")}}
+
+
+
{{Glossary("Forbidden header name")}}
+
no
+
+
+
+
+## Sintaxis
+
+```
+Content-Security-Policy: ;
+```
+
+## Directivas
+
+### {{Glossary("Fetch directive", "Fetch directives")}}
+
+"Fetch directives" controla la ubicación o ubicaciones desde la cual se pueden cargar ciertos tipos de recursos
+
+#### Lista de Content Security Policy Fetch directives
+
+- {{CSP("child-src")}}
+
+ - : Define los origenes válidos para [web workers](/es/docs/Web/API/Web_Workers_API) y contextos de navegación anidados cargados usando elementos como {{HTMLElement("frame")}} and {{HTMLElement("iframe")}}.
+
+ > **Advertencia:** En lugar de **`child-src`**, los autores quienes deseen regular los contextos de navegación anidados y "workers" deberían usar las directivas {{CSP("frame-src")}} y {{CSP("worker-src")}}, respectivamente.
+
+- {{CSP("connect-src")}}
+ - : Restringe las URLs que pueden ser cargados usando scripts.
+- {{CSP("default-src")}}
+ - : Serves as a fallback for the other {{Glossary("Fetch directive", "fetch directives")}}.
+- {{CSP("font-src")}}
+ - : Especifica origenes válidos para las fuentes cargadas usando {{cssxref("@font-face")}}.
+- {{CSP("frame-src")}}
+ - : Especifica origenes válidos para contextos de navageción anidada cargados usando elementos como {{HTMLElement("frame")}} y {{HTMLElement("iframe")}}.
+- {{CSP("img-src")}}
+ - : Especifica origenes válidos de imágenes y favicons.
+- {{CSP("manifest-src")}}
+ - : Especifica origenes válidos de archivos de manifiesto de una aplicación.
+- {{CSP("media-src")}}
+ - : Especifica origenes válidos para carga de archivos usando elementos como {{HTMLElement("audio")}} , {{HTMLElement("video")}} y {{HTMLElement("track")}}.
+- {{CSP("object-src")}}
+ - : Specifies valid sources for the {{HTMLElement("object")}}, {{HTMLElement("embed")}}, and {{HTMLElement("applet")}} elements.
+
+
+ Elements controlled by `object-src` are perhaps coincidentally considered legacy HTML elements and aren't recieving new standardized features (such as the security attributes `sandbox` or `allow` for `
