path: root/files/ko/web/http/headers/set-cookie/index.html

---
title: Set-Cookie
slug: Web/HTTP/Headers/Set-Cookie
tags:
  - HTTP
  - 레퍼런스
  - 응답
  - 쿠키
  - 헤더
translation_of: Web/HTTP/Headers/Set-Cookie
---
<div>{{HTTPSidebar}}</div>

<p><strong><code>Set-Cookie</code></strong> HTTP 응답 헤더는 서버에서 사용자 브라우저에 쿠키를 전송하기 위해 사용됩니다.</p>

<p>자세한 정보를 보려면 <a href="/en-US/docs/Web/HTTP/Cookies">HTTP cookies</a>에 수록된 가이드를 읽으세요.</p>

<table class="properties">
 <tbody>
  <tr>
   <th scope="row">Header type</th>
   <td>{{Glossary("Response header")}}</td>
  </tr>
  <tr>
   <th scope="row">{{Glossary("Forbidden header name")}}</th>
   <td>no</td>
  </tr>
 </tbody>
</table>

<h2 id="문법">문법</h2>

<pre class="syntaxbox">Set-Cookie: &lt;cookie-name&gt;=&lt;cookie-value&gt;
Set-Cookie: &lt;cookie-name&gt;=&lt;cookie-value&gt;; Expires=&lt;date&gt;
Set-Cookie: &lt;cookie-name&gt;=&lt;cookie-value&gt;; Max-Age=&lt;non-zero-digit&gt;
Set-Cookie: &lt;cookie-name&gt;=&lt;cookie-value&gt;; Domain=&lt;domain-value&gt;
Set-Cookie: &lt;cookie-name&gt;=&lt;cookie-value&gt;; Path=&lt;path-value&gt;
Set-Cookie: &lt;cookie-name&gt;=&lt;cookie-value&gt;; Secure
Set-Cookie: &lt;cookie-name&gt;=&lt;cookie-value&gt;; HttpOnly

Set-Cookie: &lt;cookie-name&gt;=&lt;cookie-value&gt;; SameSite=Strict
Set-Cookie: &lt;cookie-name&gt;=&lt;cookie-value&gt;; SameSite=Lax

// Multiple directives are also possible, for example:
Set-Cookie: &lt;cookie-name&gt;=&lt;cookie-value&gt;; Domain=&lt;domain-value&gt;; Secure; HttpOnly
</pre>

<h2 id="디렉티브">디렉티브</h2>

<dl>
 <dt><code>&lt;cookie-name&gt;=&lt;cookie-value&gt;</code></dt>
 <dd>쿠키는 "이름-값" 페어로 시작됩니다.
 <ul>
  <li><code>&lt;cookie-name&gt;</code> 는 제어 문자 및 공백, 탭(\t)를 제외한 아스키 문자로 구성되어야 합니다. 또한, "( ) &lt; &gt; @ , ; : \ " /  [ ] ? = { }" 같은 문자도 포함할 수 없습니다.</li>
  <li>A <code>&lt;cookie-value&gt;</code> 는 필요하다면 쌍 따운표로 묶여질 수 있고 아스키 코드 문자로 구성되어야 하고, <code>&lt;cookie-name&gt;</code>처럼 제어 문자, 공백, 쌍 따운표, 콤마, 세미콜론, 역 슬래쉬(\)는 사용할 수 없습니다. <strong>엔코딩</strong>: 쿠기 값에 대해서 URL 엔코딩을 사용하는 구현 기법들이 많지만, RFC 명세에서 요구하는 것은 아닙니다. 단지, &lt;cookie-value&gt;에 허용된 문자에 대한 요구사항을 만족시킬 뿐이죠.</li>
  <li><strong><code>__Secure-</code> 프리픽스</strong>:<code> __Secure-</code> (대쉬는 프리픽스의 일부입니다)로 시작되는 쿠키 이름은 반드시 <code>secure</code> 플래그가 설정되어야 하고, 보안 페이지(HTTPS)여야 합니다.</li>
  <li><strong><code>__Host-</code> 프리픽스</strong>: <code>__Host-</code> 로 시작되는 쿠키들은 <code>secure</code> 플래그가 설정되어야 하며, 마찬가지로 보안 페이지(HTTPS)여야 하고, 도메인이 지정되지 않아야 합니다. (따라서 서브 도메인에 쿠키를 공유할 수 없습니다) 그리고, 경로는 반드시 "/"여야 합니다.</li>
 </ul>
 </dd>
 <dt>Expires=&lt;date&gt; {{optional_inline}}</dt>
 <dd>
 <p>HTTP 타임스템프로 기록된 쿠키의 최대 생존 시간(수명). 세부 형태를 확인하려면 {{HTTPHeader("Date")}}를 참조하세요. 지정되지 않았다면, <strong>세션 쿠키</strong>로서 취급되며, 클라이언트가 종료될 때 파기 됩니다. 그러나 많은 웹 브라우져에서 세션이라고 불리는 기능(그러니까 모든 탭을 기억했다가 브라우져를 다시 켜면 복구된다던지 하는 기능)을 구현합니다. 쿠키들 또한 함께 복원되므로, 정확히 말해서 브라우져를 닫은 적이 없는 게 되는 것이죠.</p>

 <p>만료 시간이 지정되면, 시간 및 날자로 이뤄진 값은 서버가 아니라 클라이언트에 상대적인 값으로 취급됩니다.</p>
 </dd>
 <dt>Max-Age=&lt;number&gt; {{optional_inline}}</dt>
 <dd>쿠키가 만료될 때 까지의 시간 (초 단위). 0 또는 음수가 지정되면 해당 쿠키는 즉시 만료되며, 오래된 브라우저(ie6, ie7 그리고 ie8)은 이 헤더를 지원하지 않습니다. 다른 브라우저들은 둘 다(<code>Expires</code> 와 <code>Max-Age)</code> 지정되었을 때 <code>Max-Age</code> 값을 더 우선시합니다.</dd>
 <dt>Domain=&lt;domain-value&gt; {{optional_inline}}</dt>
 <dd>쿠키가 적용되어야 하는 호스트를 지정. 지정되어 있지 않으면 현재 문서 URI를 기준으로 적용됩니다만, 서브 도메인을 포함하지 않습니다. 이전의 설계와 달리, 도메인의 선두에 위치한 점들은 무시됩니다. 도메인이 지정되면, 서브도메인들은 항상 포함됩니다.</dd>
 <dt>Path=&lt;path-value&gt; {{optional_inline}}</dt>
 <dd>쿠키 헤더를 보내기 전에 요청 된 리소스에 있어야하는 URL 경로를 나타냅니다. % x2F ( "/") 문자는 디렉토리 구분 기호로 해석되며 하위 디렉토리도 일치합니다 (예: path=/docs, "/docs", "/docs/Web/"또는 "/docs/Web/HTTP "가 모두 일치합니다).</dd>
 <dt>Secure {{optional_inline}}</dt>
 <dd>보안 쿠키들은 서버에서 요청이 SSL을 사용하며, HTTPS 프로토콜을 사용할 때에만 전송됩니다. 그러나 기밀 정보나 민감한 정보들은 HTTP 쿠키에 보관되거나 그걸로 전송되어선 안됩니다. 왜냐하면, 그 전체 메커니즘이 본질적으로 보안이 결여되어 있고, 거기 들어있는 어떤 정보도 암호화되지 않기 때문입니다.
 <p class="note"><strong>노트:</strong> 비 보안 사이트(<code>http:</code>)들은 "보안" 쿠키를 더이상 설정할 수 없습니다(Chrome 52+ 및 Firefox 52+).</p>
 </dd>
 <dt>HttpOnly {{optional_inline}}</dt>
 <dd>HTTP-only cookies aren't accessible via JavaScript through the property, the {{domxref("XMLHttpRequest")}} and {{domxref("Request")}} APIs to mitigate attacks against cross-site scripting ({{Glossary("XSS")}}).</dd>
 <dt>SameSite=Strict<br>
 SameSite=Lax {{optional_inline}} {{experimental_inline}}</dt>
 <dd>
 <p>Allows servers to assert that a cookie ought not to be sent along with cross-site requests, which provides some protection against cross-site request forgery attacks ({{Glossary("CSRF")}}).</p>
 </dd>
</dl>

<h2 id="Examples">Examples</h2>

<h3 id="Session_cookie">Session cookie</h3>

<p>Session cookies will get removed when the client is shut down. They don't specify the <code>Expires</code> or <code>Max-Age</code> directives. Note that web browser have often enabled session restoring.</p>

<pre>Set-Cookie: sessionid=38afes7a8; HttpOnly; Path=/</pre>

<h3 id="Permanent_cookie">Permanent cookie</h3>

<p>Instead of expiring when the client is closed, permanent cookies expire at a specific date (<code>Expires</code>) or after a specific length of time (<code>Max-Age</code>).</p>

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

<h3 id="Invalid_domains">Invalid domains</h3>

<p>A cookie belonging to a domain that does not include the origin server <a href="https://tools.ietf.org/html/rfc6265#section-4.1.2.3">should be rejected by the user agent</a>. The following cookie will be rejected if it was set by a server hosted on originalcompany.com.</p>

<pre>Set-Cookie: qwerty=219ffwef9w0f; Domain=somecompany.co.uk; Path=/; Expires=Wed, 30 Aug 2019 00:00:00 GMT</pre>

<h3 id="Cookie_prefixes">Cookie prefixes</h3>

<p>Cookies names with the prefixes <code>__Secure-</code> and <code>__Host-</code> can be used only if they are set with the <code>secure</code> directive from a secure (HTTPS) origin. In addition, cookies with the <code>__Host-</code> prefix must have a path of "/" (the entire host) and must not have a domain attribute. For clients that don't implement cookie prefixes, you cannot count on having these additional assurances and the cookies will always be accepted.</p>

<pre>// Both accepted when from a secure origin (HTTPS)
Set-Cookie: __Secure-ID=123; Secure; Domain=example.com
Set-Cookie: __Host-ID=123; Secure; Path=/

// Rejected due to missing Secure directive
Set-Cookie: __Secure-id=1

// Rejected due to the missing Path=/ directive
Set-Cookie: __Host-id=1; Secure

// Rejected due to setting a domain
Set-Cookie: __Host-id=1; Secure; Path=/; domain=example.com
</pre>

<h2 id="Specifications">Specifications</h2>

<table class="standard-table">
 <tbody>
  <tr>
   <th scope="col">Specification</th>
   <th scope="col">Title</th>
  </tr>
  <tr>
   <td>{{RFC("6265", "Set-Cookie", "4.1")}}</td>
   <td>HTTP State Management Mechanism</td>
  </tr>
  <tr>
   <td><a href="https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-02">draft-ietf-httpbis-rfc6265bis-02</a></td>
   <td>Cookie Prefixes, Same-Site Cookies, and Strict Secure Cookies</td>
  </tr>
 </tbody>
</table>

<h2 id="Browser_compatibility">Browser compatibility</h2>

<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p>

<p>{{Compat("http.headers.Set-Cookie")}}</p>

<h2 id="Compatibility_notes">Compatibility notes</h2>

<ul>
 <li>Starting with Chrome 52 and Firefox 52, insecure sites (<code>http:</code>) can't set cookies with the "secure" directive anymore.</li>
</ul>

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

<ul>
 <li><a href="/en-US/docs/Web/HTTP/Cookies">HTTP cookies</a></li>
 <li>{{HTTPHeader("Cookie")}}</li>
 <li>{{domxref("Document.cookie")}}</li>
</ul>