of course 아님 (엌ㅋㅋㅋㅋㅋ)
죄송합니다 너무 쓰고 싶어서 그만 ..
Cross-Origin Resource Sharing의 약자로 리소스를 가지고 있는 서비스 밖의 다른 도메인 또는 포트의 서비스에서 리소스에 접근할 수 있게 권한을 부여도록 브라우저에 알려주는 체제입니다.
여기서 Cross-Origin이란 우리 말로 교차 출처라는 뜻인데 출처가 다르다는 뜻으로 이해하면 됩니다.
이때 출처(Origin)이 무엇인지 먼저 알아야합니다.
제가 매일 접속하는 네이버 웹툰 URL을 예로 구성 요소를 분리해봅시다.
네이버 웹툰 독립일기 71화의 URL입니다.
https://comic.naver.com/webtoon/detail.nhn?titleId=748105&no=72&weekday=sun
https://
: 프로토콜comic.naver.com
: 호스트/webtoon/detail.nhn
: Path?titleId=748105&no=72&weekday=sun
: 쿼리 문자열#
을 시작으로 하는 문자열은 Fragment 입니다.위의 예에서 출처(Origin)는 프로토콜, 호스트와 생략되어 있지만 포트 번호(:80
, :443
, ...)까지 포함된 것을 의미합니다.
http://somesite.domain:123
과 http://somesite.domain:456
은 프로토콜과 도메인은 같으나 포트 번호가 다르기 때문에 같은 출처가 아닌겁니다.
현재 제 서버와 클라이언트 사이 관계로 실제 발생한 문제를 예로 들겠습니다.
https://헤로쿠_앱_이름.herokuapp.com
https://버셀_앱_이름.vercel.app
위와 같이 서버와 클라이언트 서버의 도메인이 다른 상황에서 클라이언트가 서버에게 쿠키 자원을 요청합니다.
서버에서는 요청에 응답해 Response에 쿠키를 담아 클라이언트에게 응답, 전송해줍니다.
이때 서버와 클라이언트의 출처가 다른 문제로 CORS 정책을 위반하여 브라우저에서는 쿠키를 저장할 수 없는 문제가 발생합니다.
제가 실행한 해결 방안은 HTTP 응답 헤더의 Access-Control-Allow-Origin
속성 값을 *
로 설정해주어 Cross-Origin 요청을 허가할 수 있도록 처리하는 방법을 사용했습니다.
"Access-Control-Allow-Origin": "*"
클라이언트 단에서 POST 요청을 전송할 때 헤더 속성을 추가해주고 서버단에서 CORS를 허용해야하는 클라이언트 도메인을 설정해주었습니다.
위외 같이 Access-Control-Allow-Origin을 *로 설정할 경우 CSRF 공격에 취약합니다.
다른 해결 방법은 Preflight Request, 프록시 서버를 거치는 전송 등이 있습니다.
+ SameSite
Chrome 브라우저에서는 2019년 10월부터
sameSite
정책의 기본값이 Lax로 변경되었습니다.이로 인해
<a>, <link> <from>
정도에서만 예외로 허용하고 그 외에는 도메인이 일치하지 않을 경우 쿠키를 저장할 수 없습니다.저같은 경우에는 서버단에서 쿠키를 담아줄 때
sameSite: 'none'
으로 설정해주었습니다. 다만, none으로 사용하기 위해서는 쿠키에Secure
가 강제됩니다.더 자세한 내용은 SameSite 내용의 출처인 HAHWUL - SameSite=Lax가 Default로? SameSite Cookie에 대해 정확하게 알아보기 포스트에 자세하게 작성되어있으니 참고해주세요.