배포 환경이 여의치 않은 경우 종종 연결 확인을 위해 일단 로컬로 붙여보자고 제안하는 경우가 있다.
어째 이럴 때마다 로그인이 종종 발목을 잡는데, 대개는 credentials 내지는 cookie 세팅이 원인이다.
cookie 설정인 secure나 samesite 등은 독립된 성질이 아니라는 점이 더욱 그런 것 같다.
이 기회에 기록을 좀 해두어야겠다.
secure
쿠키를 암호화된 방식으로 보낼 것인지에 대한 인자이다.
이 암호화는 SSL 계층을 통해 진행되므로, https 방식으로 통신하지 않으면 true로 설정했더라도 적용되지 않는다.
또한 sameSite=none
은 secure가 true일 때만 적용된다.
httpOnly
브라우저 단에서 쿠키에 접속하는 것을 제한하기 위한 설정이다.
true로 설정하면 XSS 등의 설정을 막을 수 있다.
sameSite
일반적으로 3rd party에 쿠키를 전달할 때 쓰이는 인자이다.
Strict인 경우 요청 서버 도메인과 다를 경우 아예 set-cookie가 되지 않으며,
lax인 경우 특정 요청(오직 GET)에 한해서만 set-cookie를 허용한다.
none은 어느 환경이든 관계없이 set-cookie를 가능하게 하나, CSRF 우려가 있어 최근에는 none으로 설정했더라도 자동으로 lax로 적용이 된다.
lax로 적용한 경우 결국 login 등의 과정이 post로 이뤄지면 쿠키가 저장되지 않는다.
해결 방법은 로컬 환경에 ssl 인증서를 적용해 연결하거나 결국은 프록시(프론트엔드)를 통해 경유하는 방법 정도인 듯 하다.
어느 쪽이든 잘못되지 않았고 로컬에 ssl 세팅을 하는 게 영 내키지 않아 결국 프론트엔드 프록시를 통해 해결했으나,
종종 이런 보안적 설정을 성가시게 여겨 proxy로 회피해버리는 quick-hack보다 좋은 방법이 없을지를 고민하게 된다.
'SERVER' 카테고리의 다른 글
nginx 프록시 설정 (0) | 2024.09.27 |
---|---|
RAID 구성 방식에 대하여 (0) | 2023.11.14 |
AWS S3 버킷 권한 목록 (0) | 2023.04.02 |