기본적으로는 none이다. 그러나 크롬에서 최근 기본 값을 lax로 인식하기 위한 준비를 하고 있다.
samesite 옵션이 필요한 이유를 보려면 우선 XSRF 공격을 알아야 한다.
bank.com 에 로그인 되어있다고 가정 했을 때 해당 사이트에서 사용 되는 인증 쿠키가 브라우저에 저장되어 있을 것이다. 이때에 서버는 전송 받은 쿠키를 식별하여 사용자를 식별할 것이다.
이제 로그인된 상태에서 창을 하나 더 띄어 evil.com 에 접속 해보자. 이 사이트는 해커에게 송금을 하는 폼 <form action="[<https://bank.com/pay>](<https://bank.com/pay>)"> 요청을 숨겨 두었다.
폼이 은행 사이트로 전송될 때 인증 쿠키도 당연히 은행 사이트에서 만든 것이기 때문에 같이 전송이 될 것이다. 그러면 은행은 전송받은 쿠키를 읽어 계정 주인이 접속한 것이라 생각하고 송금을 하게 될 것이다.
이러한 공격을 크로스 사이트 요청 위조라고 부른다.
실제 은행은 물론 이 공격을 막을 수 있도록 설계되어 있는데 XSRF 토큰을 이용해서 이 공격을 막을 수 있다. 폼 요청 마다 별도의 토큰을 확인해 내가 발급한 요청이 맞는지 확인한다.
하지만 이러한 절차는 구현에 시간이 걸린다는 단점을 수반한다. 모든 폼에 보호 토큰을 세팅 해줘야 한다는 것이다. 또한 요청 전부를 검수 해야 한다.
이 옵션을 이용하면 이론상 XSRF 보호 토큰 없이도 크로스 사이트 요청 위조를 막을 수 있다. samesite 만 설정해도 자동으로 strict로 설정된다.
요청이 사이트 외부에서 일어날 때 (폼 전송, 링크 이동, 브라우저에 URL 입력 등) strict 옵션이 설정된 쿠키는 절대로 서버로 전송되지 않는다. 이 보호 장치는 꽤나 믿을 만하다. 그러나 불편함도 감수해야 한다.