• SameSite에 대해 처음 알았을땐 사실 도메인에 대한 기준에 별 관심이 없어서 그냥 지나쳤었는데, 최근에 이와 관련해서 테스트 해보고 여러 의견을 나눠본 결과.. 매우 중요 하다는 것을 알게되었다.

그 이유는 same-site는 cookie를 서로 공유할수 있기 때문이다.

이 글은 cookie의 설정값을 알아보기 더불어 same-site의 정확한 기준이 무엇인지 기록한다.

엥;; 우린 cookie 잘 쓰고 있는데 왜그러세요

맞다. 잘 쓰고 있었을 것이다. 왜냐하면 원래 cookie에 대한 정책 자체가 그렇게 빡세지 않았다.

현재 가장 널리 쓰이고 있는 Chrome 브라우저 기준으로 Chrome 84 버전부터 cookie 정책이 바뀌게 되었다.

(아마 이때 많은 개발자들이 혼란을 겪었으리라)

cookie의 속성중 SameSite 라는 속성이 Chrome 84 부터는 아무 설정이 없으면 Lax 를 기본으로 설정하게 된다.

SameSite의 속성에는 아래 3가지가 있다.

1. Strict: 같은 도메인에서만 접근 가능
2. Lax: a tag, link tag 같은 곳을 통해서 이동했을때만 cookie 전송됨.
3. None: cross-site에서도 쿠키 전송 가능해짐. 단, Secure 옵션을 추가해야함. 그렇지 않으면 거부됨 (ex.SameSite=None; Secure )

의도한것이 아니라면 SameSite=None; 이 사용되지 않도록 하려는 것이 보인다.

cookie의 ‘전송’이 무엇을 말하는데?

cookie의 전송에는 브라우저 → 서버와 서버 → 브라우저 가 있다.

원래 브라우저는 도메인별로 쿠키를 가지고 있고 다른 도메인으로 이동한다고 쿠키가 삭제되지 않는다.

GET이나 POST 등의 요청을 서버로 보낼때 브라우저는 현재 가지고 있는 cookie를 서버로 보내도록 되어있다.

반대로, 서버는 클라이언트로 응답을 보낼때 set-cookie라는 속성으로 브라우저에게 cookie를 저장하라고 명령할수 있다.

자, 이제 위에서 나온 same-site 규칙을 기반으로 이 상황을 다시 보면 클라이언트가 아무리 웃기는 짬뽕짓을 해서 cookie를 갖고 뭘 해도 same-site 규칙이 올바르게 정해져 있다면 다른 도메인의 cookie가 실수로 전송 될 일이 없다. 서버는 의도하지 않은 도메인에 cookie를 전달해도 이 세팅에 의해 cookie는 전송되지 않을 것이다.

그럼 Same-site를 판단하는 기준은 뭘까

www.google.com

과

aaa.google.com

즉 서브 도메인만 다른 경우 SameSite인가? 이고 결론은 SameSite 이다.

다만 하나 알고가야할건, 이를 나누는 기준이 Public suffix(공개 접미사)에 명시된 최상위 도메인을 비교한다는 것이다. suffix가 .com 이라면 suffix 앞까지를 하나의 site로 보는 것이다. 위 예시에서는 google.com이 하나의 site이다.

그래서,

a.google.com

과

b.google.com

은 SameSite이지만,

a.github.io

와

b.github.io

는 cross-site 이다. 여기서는 io가 public suffix가 아니고 github.io 가 suffix이기 때문에 a.github.io 가 하나의 site이기 때문이다.

또한 suffix도 apigee.io 같이 .io로 다양하게 있지만 현재 도메인에 적용되는 제일 긴 suffix를 기준으로 한다는 점도 잊지 말아야 한다.

Reference

• web.dev