diff --git a/files/ko/web/http/cors/index.md b/files/ko/web/http/cors/index.md index f218b242adc720..d1cf0b29e28648 100644 --- a/files/ko/web/http/cors/index.md +++ b/files/ko/web/http/cors/index.md @@ -342,25 +342,39 @@ CORS 사전 요청에는 자격 증명이 절대로 포함되지 않아야 합 #### 자격 증명이 포함된 요청과 와일드카드 -자격 증명 요청에 응답할 때 서버는 **반드시** "`*`" 와일드카드를 지정하는 대신 `Access-Control-Allow-Origin` 헤더 값에 출처를 지정해야 합니다. +자격 증명이 포함된 요청에 응답하는 경우: -위 예제의 요청 헤더에 `Cookie` 헤더가 포함되어 있기 때문에 `Access-Control-Allow-Origin` 헤더의 값이 "\*"인 경우 요청이 실패합니다. 위 요청은 `Access-Control-Allow-Origin` 헤더가 "`*`" 와일드 카드가 아니라 "`http://foo.example`" 본래 주소이기 때문에 자격증명 인식 컨텐츠는 웹 호출 컨텐츠로 리턴됩니다. +- 서버는 `Access-Control-Allow-Origin` 응답 헤더 값으로 "`*`" 와일드카드를 **지정해서는 안 되며**, 대신 명시적인 출처를 지정해야 합니다. 예를 들어 `Access-Control-Allow-Origin: https://example.com`. -위 예제의 `Set-Cookie` 응답 헤더는 추가 쿠키를 설정합니다. 실패한 경우 사용한 API에 따라 예외가 발생합니다. +- 서버는 `Access-Control-Allow-Headers` 응답 헤더 값으로 "`*`" 와일드카드를 **지정해서는 안 되며**, 대신 명시적인 헤더 이름 목록을 지정해야 합니다. 예를 들어 `Access-Control-Allow-Headers: X-PINGOTHER, Content-Type`. -#### Third-party cookies +- 서버는 `Access-Control-Allow-Methods` 응답 헤더 값으로 "`*`" 와일드카드를 **지정해서는 안 되며**, 대신 명시적인 메서드 이름 목록을 지정해야 합니다. 예를 들어 `Access-Control-Allow-Methods: POST, GET`. -CORS 응답에 설정된 쿠키에는 일반적인 third-party cookie 정책이 적용됩니다. 위의 예제는 `foo.example`에서 페이지를 불러지만 20행의 쿠키는 `bar.other` 가 전송합니다. 때문에 사용자의 브라우저 설정이 모든 third-party cookies를 거부하도록 되어 있다면, 이 쿠키는 저장되지 않습니다. +- 서버는 `Access-Control-Expose-Headers` 응답 헤더 값으로 "`*`" 와일드카드를 **지정해서는 안 되며**, 대신 명시적인 헤더 이름 목록을 지정해야 합니다. 예를 들어 `Access-Control-Expose-Headers: Content-Encoding, Kuma-Revision`. + +요청에 자격 증명(가장 일반적으로는 `쿠키` 헤더)이 포함되고 응답에 `Access-Control-Allow-Origin: *` 헤더(즉, 와일드카드)가 포함되어 있으면, 브라우저는 응답에 대한 접근을 차단하고 개발자 도구 콘솔에 CORS 오류를 보고합니다. + +그러나 요청에 자격 증명(예를 들어 `쿠키` 헤더)이 포함되고 응답에 와일드카드 대신 실제 출처(예를 들어 `Access-Control-Allow-Origin: https://example.com`)가 포함되어 있으면, 브라우저는 지정된 출처에서 응답에 접근할 수 있도록 허용합니다. + +또한 응답의 `Access-Control-Allow-Origin` 헤더 값에 실제 출처가 아닌 "`*`" 와일드카드인 경우 해당 응답의 `Set-Cookie` 헤더에 쿠키를 설정하지 않습니다. + +#### 서드-파티 쿠키 + +CORS 응답에 설정된 쿠키는 일반적인 서드-파티(third-party) 쿠키 정책의 적용을 받습니다. 위의 예에서, 페이지는 `foo.example` 에서 로드되지만, 응답의 `Cookie` 헤더는 `bar.other` 에서 전송되므로 사용자의 브라우저가 모든 서드-파티 쿠키를 거부하도록 설정된 경우 해당 쿠키는 저장되지 않습니다. + +요청의 쿠키도 일반적인 서드-파티 쿠키 정책에 따라 억제될 수 있습니다. 따라서 강제된 쿠키 정책은 이 장에서 설명된 기능을 무효화하여 자격 증명이 포함된 요청을 전혀 수행할 수 없게 만들 수 있습니다. + +[SameSite](/ko/docs/Web/HTTP/Headers/Set-Cookie#samesitesamesite-value) 속성에 대한 쿠키 정책이 적용됩니다. ## HTTP 응답 헤더 -이 섹션에서는 Cross-Origin 리소스 공유 명세에 정의된 대로 서버가 접근 제어 요청을 위해 보내는 HTTP 응답 헤더가 나열되어 있습니다. The previous section gives an overview of these in action. +이 섹션에서는 교차 출처 리소스 공유 명세에 정의된 대로 서버가 접근 제어 요청을 위해 보내는 HTTP 응답 헤더가 나열되어 있습니다. 이전 섹션에서는 이러한 내용이 실제로 어떻게 작동하는지에 대한 개요를 제공합니다. ### Access-Control-Allow-Origin 리턴된 리소스에는 다음 구문과 함께 하나의 {{HTTPHeader("Access-Control-Allow-Origin")}} 헤더가 있을 수 있습니다. -``` +```http Access-Control-Allow-Origin: | * ``` @@ -368,23 +382,24 @@ Access-Control-Allow-Origin: | * 예를들어 `https://mozilla.org` 의 코드가 리소스에 접근 할 수 있도록 하려면 다음과 같이 지정할 수 있습니다. -``` +```http Access-Control-Allow-Origin: https://mozilla.org +Vary: Origin ``` -서버가 "`*`" 와일드카드 대신에 하나의 origin을 지정하는 경우, 서버는 {{HTTPHeader("Vary")}} 응답 헤더에 `Origin` 을 포함해야 합니다. 이 origin은 화이트 리스트의 일부로 요청 origin에 따라 동적으로 변경될 수 있습니다. 서버 응답이 {{HTTPHeader("Origin")}} 요청 헤더에 따라 다르다는것을 클라이언트에 알려줍니다. +서버가 "`*`" 와일드카드 대신에 하나의 출처를 지정하는 경우, 서버는 {{HTTPHeader("Vary")}} 응답 헤더에 `Origin` 을 포함해야 합니다. 이 출처는 화이트 리스트의 일부로 요청 출처에 따라 동적으로 변경될 수 있습니다. 서버 응답이 {{HTTPHeader("Origin")}} 요청 헤더에 따라 다르다는 것을 클라이언트에 알려줍니다. ### Access-Control-Expose-Headers -{{HTTPHeader("Access-Control-Expose-Headers")}} 헤더를 사용하면 브라우저가 접근할 수 있는 헤더를 서버의 화이트리스트에 추가할 수 있습니다. +{{HTTPHeader("Access-Control-Expose-Headers")}} 헤더는 JavaScript(예를 들어 {{domxref("Response.headers")}})가 브라우저에서 접근할 수 있는 허용된 헤더 목록에 지정된 헤더를 추가합니다. -``` +```http Access-Control-Expose-Headers: [, ]* ``` 예를들면 다음과 같습니다. -``` +```http Access-Control-Expose-Headers: X-My-Custom-Header, X-Another-Custom-Header ``` @@ -394,7 +409,7 @@ Access-Control-Expose-Headers: X-My-Custom-Header, X-Another-Custom-Header {{HTTPHeader("Access-Control-Max-Age")}} 헤더는 preflight request 요청 결과를 캐시할 수 있는 시간을 나타냅니다. preflight request 예제는 위를 참조하세요. -``` +```http Access-Control-Max-Age: ``` @@ -402,45 +417,45 @@ Access-Control-Max-Age: ### Access-Control-Allow-Credentials -{{HTTPHeader("Access-Control-Allow-Credentials")}} 헤더는 `credentials` 플래그가 true일 때 요청에 대한 응답을 표시할 수 있는지를 나타냅니다. preflight request에 대한 응답의 일부로 사용하는 경우, credentials을 사용하여 실제 요청을 수행할 수 있는지를 나타냅니다. simple `GET` requests는 preflighted되지 않으므로 credentials이 있는 리소스를 요청하면, 이 헤더가 리소스와 함께 반환되지 않습니다. 이 헤더가 없으면 브라우저에서 응답을 무시하고 웹 컨텐츠로 반환되지 않는다는 점을 주의하세요. +{{HTTPHeader("Access-Control-Allow-Credentials")}} 헤더는 `자격 증명 플래그`가 true 일 때 요청에 대한 응답을 표시할 수 있는지 여부를 나타냅니다. 사전 요청에 대한 응답의 일부로 사용될 때, 이 헤더는 실제 요청이 자격 증명과 함께 수행될 수 있는지 여부를 나타냅니다. 단, GET 메서드 단순 요청은 사전 요청이 수행되지 않으므로, 자격 증명과 함께 리소스에 대한 요청이 이루어진 경우 이 헤더가 리소스와 함께 반환되지 않으면 브라우저는 응답을 무시하고 웹 콘텐츠에 반환하지 않습니다. -``` +```http Access-Control-Allow-Credentials: true ``` -[Credentialed requests](#requests_with_credentials) 은 위에 설명되어 있습니다. +[자격 증명이 포함된 요청](#requests_with_credentials)은 위에서 논의하였습니다. ### Access-Control-Allow-Methods -{{HTTPHeader("Access-Control-Allow-Methods")}} 헤더는 리소스에 접근할 때 허용되는 메서드를 지정합니다. 이 헤더는 preflight request에 대한 응답으로 사용됩니다. 요청이 preflighted 되는 조건은 위에 설명되어 있습니다. +{{HTTPHeader("Access-Control-Allow-Methods")}} 헤더는 리소스에 접근할 때 허용되는 메서드를 지정합니다. 이 헤더는 사전 요청에 대한 응답으로 사용됩니다. 사전 요청이 발생하는 조건은 위에서 논의하였습니다. -``` +```http Access-Control-Allow-Methods: [, ]* ``` -이 헤더를 브라우저로 전송하는 예제를 포함하여 [preflight request 의 예제는](#preflighted_requests), 위에 나와 있습니다. +위에 [사전 요청](#preflighted_requests)의 예가 제공되어 있으며, 이 예시에는 이 헤더를 브라우저에 전송하는 예가 포함되어 있습니다. ### Access-Control-Allow-Headers -[preflight request](#preflighted_requests) 에 대한 응답으로 {{HTTPHeader("Access-Control-Allow-Headers")}} 헤더가 사용됩니다. 실제 요청시 사용할 수 있는 HTTP 헤더를 나타냅니다. +{{HTTPHeader("Access-Control-Allow-Headers")}} 헤더는 사전 요청에 대한 응답으로 사용되며, 실제 요청을 할 때 사용할 수 있는 HTTP 헤더를 나타냅니다. 이 헤더는 브라우저의 {{HTTPHeader("Access-Control-Request-Headers")}} 헤더에 대한 서버 측 응답입니다. -``` +```http Access-Control-Allow-Headers: [, ]* ``` ## HTTP 요청 헤더 -이 섹션에는 cross-origin 공유 기능을 사용하기 위해 클라이언트가 HTTP 요청을 발행할 때 사용할 수 있는 헤더가 나열되어 있습니다. 이 헤더는 서버를 호출할 때 설정됩니다. cross-site {{domxref("XMLHttpRequest")}} 기능을 사용하는 개발자는 프로그래밍 방식으로 cross-origin 공유 요청 헤더를 설정할 필요가 없습니다. +이 섹션에서는 클라이언트가 교차 출처 공유 기능을 사용하기 위해 HTTP 요청을 발행할 때 사용할 수 있는 헤더들을 나열합니다. 이러한 헤더는 서버에 요청을 보낼 때 자동으로 설정됩니다. 교차 출처 요청을 만드는 개발자는 이러한 교차 출처 공유 요청 헤더를 프로그래밍적으로 설정할 필요가 없습니다. ### Origin -{{HTTPHeader("Origin")}} 헤더는 cross-site 접근 요청 또는 preflight request의 출처를 나타냅니다. +{{HTTPHeader("Origin")}} 헤더는 교차 출처 접근 요청 또는 사전 요청 출처를 나타냅니다. -``` +```http Origin: ``` -origin 은 요청이 시작된 서버를 나타내는 URI 입니다. 경로 정보는 포함하지 않고, 오직 서버 이름만 포함합니다. +Origin 헤더 값은 요청이 시작된 서버를 나타내는 URI 입니다. 경로 정보는 포함하지 않고, 오직 서버 이름만 포함합니다. > **참고:** `origin` 값은 `null` 또는 URI 가 올 수 있습니다. @@ -448,9 +463,9 @@ origin 은 요청이 시작된 서버를 나타내는 URI 입니다. 경로 정 ### Access-Control-Request-Method -{{HTTPHeader("Access-Control-Request-Method")}} 헤더는 실제 요청에서 어떤 HTTP 메서드를 사용할지 서버에게 알려주기 위해, preflight request 할 때에 사용됩니다. +{{HTTPHeader("Access-Control-Request-Method")}} 헤더는 실제 요청에서 어떤 HTTP 메서드를 사용할지 서버에게 알려주기 위해, 사전 요청할 때 사용됩니다. -``` +```http Access-Control-Request-Method: ``` @@ -458,10 +473,10 @@ Access-Control-Request-Method: ### Access-Control-Request-Headers -{{HTTPHeader("Access-Control-Request-Headers")}} 헤더는 실제 요청에서 어떤 HTTP 헤더를 사용할지 서버에게 알려주기 위해, preflight request 할 때에 사용됩니다. +{{HTTPHeader("Access-Control-Request-Headers")}} 헤더는 사전 요청을 발행할 때 사용되며, 실제 요청에서 사용할 HTTP 헤더를 서버에 알리기 위해 사용됩니다 (예를 들어 [`headers`](/ko/docs/Web/API/RequestInit#headers) 옵션을 통해 전달). 이 브라우저 측 헤더는 {{HTTPHeader("Access-Control-Allow-Headers")}} 라는 서버 측 헤더로 응답받게 됩니다. -``` -Access-Control-Request-Headers: [, ]* +```http +Access-Control-Request-Headers: [,]* ``` 이 사용법의 예제는 [위에서](#preflighted_requests) 찾을 수 있습니다.