SOP & CORS

SOP

Same-Origin Policy의 줄임말로, 동일 출처 정책을 뜻한다. 즉, 같은 출처의 리소스마나 공유가 가능하다'는 말이다.


출처(Origin)란 프로토콜, 호스트, 포트의 조합으로 이루어져있다. 이 중 하나라도 다르면 동일한 출처라고 볼 수 없으며, 이러한 정책은 해로울 수 있는 문서로부터 공격받을 수 있는 경로를 줄여준다. 해킹 등의 위협에서 안전해질 수 있기 때문에 모든 브라우저에서 기본적으로 사용하고 있는 정책이다.

CORS

SOP는 보안상의 이점 때문에 많이 사용되지만, 다른 출처의 리소스를 사용하게 되는 경우에서 문제가 생긴다. 개발 중인 웹 사이트에서 날씨 API를 받아오고 싶거나, 클라이언트와 서버를 따로 개발할 때 등 다른 출처의 리소스를 사용해야 하는 일에 문제가 생긴다. 이러한 문제 상황을 해결하기 위해 CORS가 등장했다.

CORS는 Cross-Origin Resource Sharing의 줄임말로 교차 출처 리소스 공유를 뜻한다. CORS를 사용하면 접근 권한을 얻을 수 있다.

CORS 동작 방식

1. 프리플라이트 요청 (Preflight Request)

실제 요청을 보내기 전, OPTIONS 메서드로 사전 요청을 보내 해당 출처 리소스에 접근 권한이 있는지부터 확인한다. 브라우저는 서버에 실제 요청을 보내기 전에 프리플라이트 요청을 보내고, 응답 헤더의 Access-Control-Allow-Origin으로 요청을 보낸 출처가 돌아오면 실제 요청을 보낸다. 만약에 요청을 보낸 출처가 접근 권한이 없다면 브라우저에서 CORS 에러를 띄우게 되고, 실제 요청은 전달되지 않는다.

프리플라이트는 실제 요청을 보내기 전에 확인할 수 있기 때문에 리소스 측면에서 효율적이다. 또한 CORS에 대비가 되어있지 않은 서버를 보호할 수도 있다.

2. 단순 요청 (Simple Request)

특정 조건이 만족되면 프리플라이트 요청을 생략하고 요청을 보낸다.
조건은 GET, HEAD, POST 요청 중 하나여야하며, Accept-Language, Content-Language, Content-Type 헤더의 값만 수동으로 설정할 수 있다.

3. 인증정보를 포함한 요청 (Credentialed Request)

출처가 다를 경우에는 별도의 설정을 하지 않으면 쿠키를 보낼 수 없다. 이 경우에는 클라이언트, 서버 양측 모두 CORS 설정이 필요하다.

  • 클라이언트에서의 허용
    - credentials 옵션을 설정해야 한다.
  • 서버에서의 허용
    - 응답 헤더의 Access-Control-Allow-Credentials 항목을 true로 설정해야 한다.
    - 응답 헤더의 Access-Control-Allow-Origin 의 값에 와일드카드 문자(”*“)는 사용할 수 없다.

profile
개발자가 되기 위해 성장 중

1개의 댓글

comment-user-thumbnail
2023년 5월 3일

CORS 문제는 프론트엔드 개발자라면 언젠가 한 번은 꼭 거쳐야 할 문제예요ㅎㅎㅎㅎ

아마 지금 잘 알고 가더라도 나중에 부딪히고 '이게 대체 왜 안 되지??' 라는 사태가 발생하죠😅

답글 달기