항해99 5주차 WIL(CORS)

CORS(Cross-Origin Resource Sharing)

• 교차(다른) 출처 리소스 공유라고 해석할 수 있다.
• 출처가 다른 웹 클라이언트와 API 서버 간의 리소스 요청 등의 상황에서 별도의 설정을 하지 않을 시 CORS 정책을 위반했다는 오류가 발생한다.
• 비신뢰적인 사이트에서 내 컴퓨터의 브라우저에 있는 쿠키 등의 정보를 통해 서버에서 정보를 탈취하는 등 비정상적인 행동을 하는 것을 방지하기 위한 정책 중 하나이다. (다른 하나는 SOP)

출처(Origin)

• url 중 protocol, hostname, port에 해당
• 이 3가지가 모두 같으면 동일 출처라고 한다.
• port는 생략이 가능하다.
• location.origin을 통해 현재 사이트의 출처를 확인할 수 있다.

SOP(Same-Origin-Policy)

• 동일 출처 정책이라고 해석할 수 있다.
• 기본적으로 브라우저는 SOP로 인해 동일 출처간의 리소스 공유만을 허용한다.
• 브라우저는 요청과 응답의 출처를 비교하여 동일한 경우에만 리소스를 성공적으로 전달한다.
• 그러나 웹에서는 다른 출처간의 리소스 공유가 필요할 때도 있기 때문에 CORS 정책을 지키면 출처가 다르더라도 리소스 공유를 가능하게 해준다.
  
  

CORS의 3가지 동작 방식

Simple Request

1. 웹 클라이언트에서 다른 출처의 리소스를 요청할 때, 브라우저는 요청 헤더의 origin 필드에 어플리케이션의 출처를 담아 보낸다.
2. 서버는 요청에 대한 응답을 보낼 때, 응답 헤더의 Access-Control-Allow-Origin에 리소스에 접근이 허용된 출처 리스트를 담아 보낸다.
3. 브라우저는 요청의 origin과 응답의 Access-Control-Allow-Origin를 비교한 후 응답이 유효한지 확인한다.

Preflight Request

• 기본적으로 Simple Request와 동작이 동일하나, Preflight Request는 요청을 예비 요청과 본 요청으로 단계를 나누어 서버에 전송한다.
• 예비 요청시 HTTP 메소드 중 OPTIONS 메소드를 사용한다. (예비 요청 === Preflight)
• 예비 요청을 통해 유효한 리소스 공유인지 확인하고 유효하면 실질적으로 본 요청을 보낸다.

Credentialed Request

• 인증된 요청을 사용하는 방법으로 다른 출처간 통신에서 좀 더 보안을 강화하고 싶을 때 사용하는 방법이다.
• Access-Control-Allow-Origin만 확인하는 것이 아닌 좀 더 빡빡한 검사 조건을 추가할 수 있다. (token 등)
• Access-Control-Allow-Origin에 와일드 카드 *를 사용할 수 없다.

CORS Flow

1. GET 요청인지  POST 요청인지 파악한다.
2. Content-Type과 Custom HTTP Header를 파악한다.
3. Option 요청을 통해서 서비스가 적절한 Access-Control를 가졌는지 확인한다.
4. 만약 적절한 Access-Control을 가졌다면 실제 XHR를 트리거 한다.
5. 적절한 Access-Control을 가지지 않았다면 Error 발생