요청에 쿠키가 안 담겨요.. SameSite=None? Strict?

🚨  TroubleShotting

문제 발생의 배경 - As Is

현재 웹소켓을 기반으로 한 실시간 투표 서비스를 개발 중이다.
서비스의 간단함을 고려하여 로그인 기능이 굳이 필요없다고 판단했지만, 투표의 주체인 유저 식별 기능은 필요했다.
따라서, 세션을 이용해서  서버에서 세션 ID를 발급 및 쿠키에 담아주면 - 프론트에서 요청마다 쿠키를 포함하는 방식으로 유저를 식별하고자 했다.

그런데 분명히 서버에서 sessionID를 발급해서 쿠키에 넣어주었고, 프론트에서도 document.cookies로 쿠키 확인이 가능하나,

요청에는 쿠키가 포함되지 않는 현상

---

How(과정) ?

시행착오 1

• Websocket 요청 헤더에 투표 정보를 담아서 백엔드로 보내려고 했다.
  • 실패
    • 웹소켓 요청은 처음에는 http로 시작하여 핸드쉐이크 -> Websocket 프로토콜로 업그레이드 되는 과정을 거친다.
    • 이 때, Websocket 프로토콜에는 Header 인터페이스 자체가 없다.
    • 즉, Websocket 프로토콜 자체는 헤더를 다룰 수 없다.

---

시행착오 2

• 그럼 핸드쉐이크 단계까지만이라도 쿠키를 담아서 요청을 보내보자.
• 프론트에서 우선 `credentials: include`(fetch) 또는`withCredentials: true`(Axios)를 설정해야 쿠키가 요청에 포함되므로 추가
  • 실패
  • 요청에 쿠키를 담아서 보낼 때는 몇 가지 조건이 필요함
    • CORS - 같은 출처인가?
      • No, 현재 프론트는 개발 모드로 `localhost:3300`, 백엔드는 `golaping.site` 주소 사용 중
      • 출처가 다르므로, Access-origin 설정 외에도 `Samesite=None` 설정 필요
      • `Samesite=None`이면, `secure=true` 설정 및 https 환경 필요
      • SSL 인증서 설치
• 이 과정을 거쳐서 `localhost:3300` 에서 백엔드 서버로 쿠키를 담아 요청 보내기에 성공했다.

---

시행착오 3

그런데, 문득 다음과 같은 생각이 들었다.

`Samesite=None`이 허용되면, CSRF 공격에 취약할 수 있지 않을까?

CSRF 공격 위험성을 막는 방법은 보통 아래 3가지이다.

• CSRF 토큰 사용
• CORS 설정 - 허용된 도메인에서만 요청을 받을 수 있도록 제한
• `SameSite=Strict` - 다른 사이트에서 쿠키가 전송되지 않도록  

---

SameSite = Strict

그 중 `SameSite=Strict`를 적용할 방법을 찾아보았다.
먼저, SameSite=Strict 란, 동일 사이트 간의 요청에만 쿠키를 주고받을 수 있는 정책이다.
그럼 여기서 동일 사이트란? 아래 이미지와 같이

• "스키마와 eTLD+1(TLD + TLD 바로 앞의 도메인)이 동일한 웹사이트" 가 동일 사이트이다.

프론트와 백엔드 간의 도메인을 일치시킬 수 있는 방법이 뭐가 있을까 생각해보았고, 2가지 방법이 떠올랐다.

방법 1

• 프론트 EC2 서버의 nginX에서 proxy_pass를 통해 Host  헤더를 백엔드 호스트로 변경 
  즉, 백엔드에서는 들어오는 요청을 같은 사이트로 인식하도록 하기

server {
    listen 80;
    server_name frontend.com;  # 프론트엔드 도메인

    location /api/ {
        proxy_pass http://api.com/;  # 백엔드 API 서버로 프록시
        proxy_set_header Host api.com;  # ---> 'Host' 헤더를 api.com으로 설정
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

• Host 헤더란?
  • HTTP 요청에서 요청을 보내는 대상의 도메인 이름을 나타낸다. 예를 들어, http://api.com/somepath로 요청을 보낼 때, Host 헤더는 api.com이 된다.

• 이렇게 하면,  백엔드 서버는 frontend.com 으로 시작한 요청이 api.com에서 온 것처럼 처리하여 `SameSite=Strict`로 설정이 가능해진다.

방법 2

프론트와 백엔드가 모두 최상위 도메인을 공유, 서브도메인으로 등록하기

Type: A
Name: frontend
Value: XX.XX.XX.XX  # EC2 퍼블릭 IP
TTL: 3600

Type: A
Name: api
Value: YY.YY.YY.YY  # 백엔드 EC2 퍼블릭 IP
TTL: 3600

• AWS Route53 서비스를 이용해서 백엔드 도메인을 서브도메인으로 설정 가능하다.

---

what(결과) - To Be

우리는 결국 서브도메인을 설정하는, 두 번째 방법을 선택했다.

근데 이 방법.. AWS의 Route53을 사용했더니 과금이 되네... 메일이 날라옴

곧 nginX 방법으로 변경할지도 모른다. 
변경하게 되면 다시 기록하자.

---

💡 새롭게 알게된 점

• 동일 출처와 동일 사이트 간의 차이에 대해서 제대로 알게 되었다.
  • 동일 출처: 스킴 + 도메인 + 포트까지 일치해야 한다.
  • 동일 사이트: 스킴 + eTLD+1 까지만 일치하면 된다(포트 달라도 됨)

---

출처

• https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie - SameSite=Strict 란
• https://web.dev/articles/same-site-same-origin?hl=ko -  동일 출처? 동일 사이트?
• https://apidog.com/kr/blog/http-host-header-2/ - Host 헤더란 무엇인가?
• https://seungyong.tistory.com/83 - 같은 SameSite 이슈를 겪은 블로거