Access-Control-Allow-Origin 헤더는 어떻게 동작합니까?

by

내가 그 의미를 완전히 오해한 것 같아.이런 생각이 들었어요.

  1. 클라이언트는 javascript 코드 MyCode.js를 에서 다운로드합니다.http://siteA– 원점.
  2. MyCode.js의 응답 헤더에는 Access-Control-Allow-Origin:이 포함되어 있습니다.이것은 MyCode.js가 사이트 B에 대한 상호 발신 참조를 할 수 있는 것을 의미합니다.
  3. 클라이언트는 MyCode.js의 몇 가지 기능을 트리거하고, 그 기능은 다음에 다음에 대한 요구를 합니다.http://siteB상호 참조 요청이지만 괜찮을 것입니다.

글쎄, 내가 틀렸어.그것은 전혀 이렇게 작동하지 않는다.따라서 w3c 권장 사항에서 크로스 오리진 리소스 공유를 읽고 크로스 오리진 리소스 공유를 읽어 보았습니다.

한 가지 확실한 것은 이 헤더를 어떻게 사용해야 하는지 아직도 잘 모르겠다는 것입니다.

사이트 A와 사이트 B를 모두 완전히 통제하고 있습니다.사이트 A에서 다운로드 받은 Javascript 코드가 이 헤더를 사용하여 사이트 B의 리소스에 액세스 할 수 있도록 하려면 어떻게 해야 합니까?

추신.

나는 JSONP를 이용하고 싶지 않다.



질문에 대한 답변



Access-Control-Allow-Origin는 CORS(Cross-Origin Resource Sharing) 헤더입니다.

사이트 A가 사이트 B에서 콘텐츠를 가져오려고 하면 사이트 B는Access-Control-Allow-Origin응답 헤더를 사용하여 브라우저에 이 페이지의 내용이 특정 오리진에 액세스할 수 있음을 알립니다(오리진은 도메인, 스킴 및 포트 번호).디폴트로는 사이트 B의 페이지는 다른 발신기지에서는 액세스 할 수 없습니다.Access-Control-Allow-Originheader를 지정하면 특정 발신기지별로 교차 액세스하기 위한 문이 열립니다.

사이트 B가 사이트 A에 액세스 할 수 있도록 하는 각 자원/페이지에 대해 사이트 B는 응답 헤더를 사용하여 페이지를 서비스해야 합니다.

Access-Control-Allow-Origin: http://siteA.com

최신 브라우저는 교차 도메인 요청을 완전히 차단하지 않습니다.사이트 A가 사이트 B에서 페이지를 요구하면 브라우저는 실제로 네트워크 수준에서 요청된 페이지를 가져와 응답 헤더가 사이트 A를 허용된 요청자 도메인으로 나열하는지 확인합니다.사이트 B가 사이트 A가 이 페이지에 액세스 할 수 있도록 허가되어 있는 것을 나타내지 않은 경우, 브라우저는,XMLHttpRequest의error요청 JavaScript 코드에 대한 응답 데이터를 이벤트 및 거부합니다.

단순하지 않은 요구

네트워크 수준에서 일어나는 일은 위에서 설명한 것보다 조금 더 복잡할 수 있습니다.요구가 “단순하지 않은” 요청인 경우 브라우저는 먼저 데이터가 없는 “사전 비행” OPTIONS 요청을 전송하여 서버가 요청을 수락하는지 확인합니다.요청은 다음 중 하나(또는 둘 다)에 해당하는 경우 단순하지 않습니다.

  • GET 또는 POST 이외의 HTTP 동사 사용(예: PUT, DELETE)
  • 단순한 요청 헤더는 다음과 같습니다.
    • Accept
    • Accept-Language
    • Content-Language
    • Content-Type(이것은, 그 값이 다음의 경우에 한정됩니다).application/x-www-form-urlencoded,multipart/form-data, 또는text/plain)

서버가 OPTIONS 프리플라이에 적절한 응답 헤더로 응답하는 경우(Access-Control-Allow-Headers비호환 헤더의 경우,Access-Control-Allow-Methods비동사 및/또는 비동사 헤더와 일치하는 비동사)의 경우 브라우저는 실제 요청을 전송합니다.

사이트 A가 다음에 대해 PUT 요구를 송신하고 싶다고 가정했을 경우/somePage, non-flashed가 있는 경우Content-Type의 가치application/json브라우저는 먼저 비행 전 요구를 전송합니다.

OPTIONS /somePage HTTP/1.1 Origin: http://siteA.com Access-Control-Request-Method: PUT Access-Control-Request-Headers: Content-Type

주의:Access-Control-Request-Method그리고.Access-Control-Request-Headers브라우저에 의해 자동으로 추가되므로 추가할 필요가 없습니다.이 OPTIONS 프리플라이는 성공한 응답 헤더를 가져옵니다.

Access-Control-Allow-Origin: http://siteA.com Access-Control-Allow-Methods: GET, POST, PUT Access-Control-Allow-Headers: Content-Type

실제 요구를 송신할 때(프리플라이트 실행 후) 동작은 단순한 요구가 처리되는 방법과 동일합니다.즉, 프리플라이가 성공하는 단순하지 않은 요구는 단순한 요구와 동일하게 취급됩니다(즉, 서버는 계속 송신할 필요가 있습니다).Access-Control-Allow-Origin(실제 응답에 대해 다시)

브라우저는 실제 요청을 전송합니다.

PUT /somePage HTTP/1.1 Origin: http://siteA.com Content-Type: application/json
{ "myRequestContent": "JSON is so great" }

그리고 서버는 이 데이터를Access-Control-Allow-Origin간단한 요청과 마찬가지로 다음과 같습니다.

Access-Control-Allow-Origin: http://siteA.com

단순하지 않은 요청에 대한 자세한 내용은 CORS 상의 XMLHttpRequest에 대해 참조하십시오.



크로스 오리진 자원 공유 –CORS(A.K.A. Cross-Domain AJAX request)는 대부분의 웹 개발자가 직면할 수 있는 문제이며, Same-Origin-Policy에 따르면 브라우저는 보안 샌드박스에서 클라이언트 JavaScript를 제한하며, 일반적으로 JS는 다른 도메인의 원격 서버와 직접 통신할 수 없습니다.지금까지 개발자들은 교차 도메인 리소스 요청을 달성하기 위해 다음과 같은 까다로운 방법을 개발했습니다.

  1. Flash/Silverlight 또는 서버 측을 “프록시”로 사용하여 원격과 통신합니다.
  2. 패딩 포함 JSON(JSONP).
  3. iframe에 리모트서버를 짜넣고, fragment 또는 window.name 를 개입시켜 통신합니다.여기를 참조해 주세요.

이러한 까다로운 방법에는 다소 문제가 있습니다.예를 들어 개발자가 단순히 JSONP를 ‘평가’하는 경우 보안에 구멍이 생길 수 있습니다.상기 #3은 두 도메인이 서로 엄격한 계약을 체결해야 합니다.이는 유연하지도 않고 우아하지도 않습니다.

W3C는 이 문제를 해결하기 위해 안전하고 유연하며 권장되는 표준 방법을 제공하기 위해 표준 솔루션으로 Cross-Origin Resource Sharing(CORS)을 도입했습니다.

메커니즘

대략적으로 보면 CORS는 도메인A로부터의 클라이언트 AJAX 콜과 도메인B 로 호스트 되는 페이지간의 계약이라고 생각할 수 있습니다.일반적인 크로스 오리진 요구/응답은 다음과 같습니다.

DomainA AJAX 요청 헤더

Host DomainB.com User-Agent Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0) Gecko/20100101 Firefox/4.0 Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8,application/json Accept-Language en-us; Accept-Encoding gzip, deflate Keep-Alive 115 Origin http://DomainA.com

DomainB 응답 헤더

Cache-Control private Content-Type application/json; charset=utf-8 Access-Control-Allow-Origin DomainA.com Content-Length 87 Proxy-Connection Keep-Alive Connection Keep-Alive

위에서 파란색으로 표시한 부분은 커널 팩트인 “Origin” 요청 헤더는 “Cross-Origin 요청 또는 프리플라이트 요청의 발신지를 나타냅니다.” 응답 헤더는 이 페이지가 도메인A로부터의 리모트 요구를 허용함을 나타냅니다(값이 *인 경우 모든 도메인으로부터의 리모트 요구를 허용함을 나타냅니다).

위에서 설명한 바와 같이 W3에서는 실제로 크로스 오리진 HTTP 요청을 제출하기 전에 “프리플라이트 요청”을 구현하도록 브라우저를 권장했습니다.간단히 말하면 HTTP입니다.OPTIONS요청:

OPTIONS DomainB.com/foo.aspx HTTP/1.1

foo.aspx가 OPTIONS HTTP 동사를 지원하는 경우 다음과 같은 응답을 반환할 수 있습니다.

HTTP/1.1 200 OK Date: Wed, 01 Mar 2011 15:38:19 GMT Access-Control-Allow-Origin: http://DomainA.com Access-Control-Allow-Methods: POST, GET, OPTIONS, HEAD Access-Control-Allow-Headers: X-Requested-With Access-Control-Max-Age: 1728000 Connection: Keep-Alive Content-Type: application/json

응답에 “Access-Control-Allow-Origin”이 포함되어 있고 그 값이 “*”이거나 CORS 요청을 제출한 도메인이 포함된 경우에만 이 명령 조건을 충족함으로써 실제 교차 도메인 요청을 전송하고 결과를 “Preflight-Result-Cache“에 캐시합니다.

저는 3년 전에 CORS에 대해 블로그에 올렸습니다.AJAX 크로스 오리진 HTTP 요청



답변하기엔 너무 오래된 질문이지만, 이 질문에 대한 향후 참조를 위해 이 글을 올립니다.

이 Mozilla Developer Network 기사에 따르면

리소스는 첫 번째 리소스 자체가 서비스하는 도메인 또는 포트와는 다른 도메인 또는 포트에서 리소스를 요청할 때 크로스 오리진 HTTP 요청을 생성합니다.

enter image description here

에서 제공되는 HTML 페이지http://domain-a.com만들다<img>src 요구http://domain-b.com/image.jpg.
오늘날 웹의 많은 페이지는 CSS 스타일시트, 이미지, 스크립트 등의 리소스를 개별 도메인에서 로드하고 있습니다(따라서 쿨해야 합니다).

동일 발신기지 정책

보안상의 이유로 브라우저는 스크립트 내에서 시작된 크로스 오리진 HTTP 요청을 제한합니다.
예를들면,XMLHttpRequest그리고.Fetch같은 방침에 따르다
그래서 웹 어플리케이션은XMLHttpRequest또는Fetch는 자신의 도메인에만 HTTP 요구를 할 수 있었습니다.

크로스 오리진 자원 공유(CORS)

웹 애플리케이션을 개선하기 위해 개발자들은 브라우저 벤더에게 교차 도메인 요청을 허용하도록 요청했습니다.

Cross-Origin Resource Sharing(CORS) 메커니즘은 웹 서버에 도메인 간 액세스 제어를 제공하여 도메인 간 데이터 전송을 안전하게 수행합니다.
최신 브라우저는 API 컨테이너에서 CORS를 사용합니다.XMLHttpRequest또는Fetch– 크로스 오리진 HTTP 요청의 위험을 완화합니다.

CORS 구조(Access-Control-Allow-Origin헤더)

위키백과:

CORS 표준에서는 새로운 HTTP 헤더를 기술하고 있습니다.이 HTTP 헤더는 브라우저와 서버에 권한이 있는 경우에만 리모트 URL을 요구할 수 있는 방법을 제공합니다.

서버에 의해 검증과 허가가 일부 수행될 수 있지만, 일반적으로 이러한 헤더를 지원하고 이러한 헤더가 부과하는 제한을 따르는 것은 브라우저의 책임입니다.

예

  1. 브라우저에 의해OPTIONS와 함께 요청하다Origin HTTPheader를 클릭합니다.

    이 헤더의 값은 상위 페이지를 서비스한 도메인입니다.다음에서 온 페이지http://www.example.com사용자 데이터에 대한 접근 시도service.example.com, 다음의 요구 헤더가 에 송신됩니다.service.example.com:

    출처 : http://www.example.com

  2. 서버:service.example.com다음과 같이 응답합니다.

    • 안Access-Control-Allow-Origin어느 송신원사이트가 허가되고 있는지를 나타내는, 그 응답의 (ACAO) 헤더.
      예를 들어 다음과 같습니다.

      Access-Control-Allow-Origin: http://www.example.com

    • 서버가 크로스 오리진 요청을 허용하지 않는 경우 오류 페이지

    • 안Access-Control-Allow-Origin(ACAO) 헤더에 모든 도메인을 허용하는 와일드카드 포함:

      Access-Control-Allow-Origin: *



CORS에 대해 생각할 때마다 당신의 질문에서 설명한 것처럼 헤더를 호스트하는 사이트에 대한 제 직관은 틀렸습니다.저는 같은 원산지 정책의 목적을 생각하는 것이 도움이 됩니다.

동일한 원본 정책의 목적은 siteB.com에서만 공유하도록 선택한 개인 정보에 액세스하는 siteA.com의 악의적인 JavaScript로부터 사용자를 보호하는 것입니다.동일한 원본 정책이 없으면 siteA.com 작성자가 작성한 JavaScript는 siteB.com 인증 쿠키를 사용하여 브라우저가 siteB.com에 요청을 할 수 있습니다.이렇게 하면 siteA.com은 siteB.com과 공유하는 비밀 정보를 훔칠 수 있습니다.

때로는 CORS가 필요한 영역을 넘나들어야 할 때도 있습니다.CORS는, siteB.com 의 같은 발신기지 정책을 완화합니다.Access-Control-Allow-Originheader를 사용하여 siteB.com과 상호 작용할 수 있는 JavaScript를 실행할 수 있는 다른 도메인(siteA.com)을 나열합니다.

CORS 헤더를 처리하는 도메인을 이해하려면 다음 사항을 고려하십시오.malicious.com에 접속합니다.이곳에는 mybank.com에 크로스 도메인 요청을 시도하는 JavaScript가 포함되어 있습니다.malicious.com의 JavaScript와 상호 작용할 수 있도록 동일한 오리진정책을 완화하는 CORS 헤더를 설정할지는 mybank.com이 아닌 mybank.com에 달려 있어야 합니다.malicous.com 가 독자적인 CORS 헤더를 설정하고, 독자적인 JavaScript 에의 mybank.com 에의 액세스를 허가할 수 있는 경우는, 같은 발신기지 정책이 완전하게 무효가 됩니다.

직관이 나쁜 이유는 사이트를 개발할 때 가지고 있는 관점이라고 생각합니다.이것은 내 사이트이며, 내 JavaScript가 모두 포함되어 있기 때문에 악의적인 행동은 하지 않으며, 내 JavaScript와 상호 작용할 수 있는 다른 사이트를 지정하는 것은 나에게 달려 있다.실제로 JavaScript가 내 사이트와 상호 작용하려고 하는 다른 사이트는 언제 생각해야 하며, 이를 허용하려면 CORS를 사용해야 합니까?



제 경험상, CORS가 왜 걱정거리인지 간단한 설명을 찾기는 어렵습니다.

그 이유를 이해하면 머리글과 토론이 훨씬 명확해집니다.몇 줄 후에 시도해 볼게요.

쿠키가 전부에요.쿠키는 도메인별로 클라이언트에 저장됩니다.

예를 들어 다음과 같습니다.컴퓨터에는 다음 쿠키가 있습니다.yourbank.com아마 네 세션이 저 안에 있을 거야

요점:클라이언트는 서버에 요청을 하면 해당 요청을 위해 도메인 아래에 저장된 쿠키를 보냅니다.

브라우저에 로그인하고 있습니다.yourbank.com모든 계정을 표시하도록 요청하면 쿠키가 다음 주소로 전송됩니다.yourbank.com.yourbank.com는 쿠키 더미를 수신하여 응답(계정)을 반환합니다.

다른 클라이언트가 서버에 크로스 오리진 요구를 하면 이전과 마찬가지로 쿠키가 전송됩니다.루노

를 참조합니다.malicious.com. 악의적으로 여러 은행에 다음과 같은 요청을 합니다.yourbank.com.

쿠키가 예상대로 검증되었으므로 서버는 응답을 승인합니다.

그 쿠키들을 모아서 보내요 – 그리고 지금,malicious.com응답이 있다yourbank.

으악!

이제 몇 가지 질문과 답변이 명확해집니다.

  • “브라우저가 그렇게 하는 것을 차단하면 어떨까요?”네, 코르스요
  • “어떻게 하면 피할 수 있을까요?”서버에 CORS가 정상임을 통지합니다.