로그인 후 다시 로그아웃될 때: 쿠키의 Domain·Path·Secure를 확인하는 순서

👤 인스피

조회 수 6

2. 첫 단계는 로그인 응답의 Set-Cookie입니다

브라우저 개발자 도구의 Network 탭에서 로그인 요청과 이동 응답을 확인합니다. Set-Cookie가 어느 응답에 붙었는지 먼저 찾습니다. 최종 페이지의 헤더만 보면 중간 이동에서 발급된 쿠키를 놓칠 수 있으므로 필요하면 요청 기록을 보존합니다.

헤더가 없다면 애플리케이션의 쿠키 설정 코드와 프록시 처리부터 확인합니다. 서버 로그에서 발급했다고 기록됐어도 중간 서비스가 헤더를 바꾸거나 제거할 수 있습니다. 다만 이번 글은 특정 CDN 설정이 원인이라고 단정하지 않습니다. 원본 응답과 브라우저가 받은 응답을 비교할 수 있을 때 차이를 확인하세요.

3. 저장 범위와 전송 범위는 속성이 결정합니다

Domain은 쿠키가 적용될 호스트 범위에 영향을 주고 Path는 요청 경로 범위에 영향을 줍니다. 속성을 생략했을 때의 기본 동작도 중요합니다. 예를 들어 특정 경로에만 적용되는 쿠키라면 다른 페이지에서 보내지지 않을 수 있습니다. 서비스가 여러 호스트를 쓰는지 함께 확인하세요.

Secure는 보안 연결에서의 전송 조건이며 HttpOnly는 JavaScript의 접근을 제한합니다. HttpOnly 쿠키가 document.cookie에 보이지 않는다고 저장 실패로 판단하면 안 됩니다. SameSite는 다른 사이트와의 요청 관계에서 전송에 영향을 줍니다. 같은 사이트와 같은 origin의 구분도 중요하므로 서브도메인이라는 이유만으로 모든 브라우저 정책이 같다고 보지 마세요.

4. 브라우저에서 세 가지 화면을 대조합니다

Network에서는 Set-Cookie 발급과 다음 요청의 Cookie 전송을 확인합니다. Application의 Cookies에서는 실제 저장된 이름, Domain, Path, Secure, SameSite, 만료 정보를 확인합니다. Issues나 쿠키 차단 안내가 있다면 그 사유도 기록합니다. 도구 이름과 위치는 브라우저 버전에 따라 달라질 수 있습니다.

같은 이름의 쿠키가 서로 다른 Domain이나 Path로 중복 저장됐는지도 확인하세요. 서버가 의도하지 않은 값을 읽는 상황이 생길 수 있습니다. 문제를 재현한 뒤 테스트 환경의 쿠키를 지우고 한 번 더 비교하면 오래된 값의 영향을 구분할 수 있습니다. 운영 사용자의 모든 쿠키를 일괄 삭제하는 방식은 먼저 권하지 않습니다.

5. 헤더 문자열 실습과 검증의 한계

아래 코드는 Python으로 쿠키 속성 문자열을 읽는 작은 실습입니다. 임의의 demo 값을 사용하며 실제 로그인 세션을 발급하지 않습니다. 출력이 기대한 속성과 같은지 확인하면 속성 이름을 읽는 연습이 됩니다. 그러나 브라우저가 이 쿠키를 받아들이는지까지 증명하는 코드는 아닙니다.

특히 브라우저의 사이트 관계 판단, HTTPS, 사용자 설정, 제삼자 쿠키 제한은 단순 문자열 파서로 재현되지 않습니다. 서버 코드의 속성이 맞아 보여도 실제 요청 경로에서 저장·전송을 다시 검사해야 합니다. 문자열 검증, 브라우저 검증, 서버 세션 검증을 나누어 기록하는 편이 결과를 정확하게 설명할 수 있습니다.

6. 쿠키가 전송됐다면 서버 검증 단계로 이동합니다

다음 요청에 올바른 쿠키가 붙었다면 세션 저장소, 만료, 서명 검증과 서버 간 설정 차이를 살펴봅니다. 여러 서버가 서로 다른 서명 키를 사용하거나 재시작 때 세션 정보가 사라지는 구조라면 전송 문제와는 다른 실패가 발생할 수 있습니다. 시간대나 시스템 시계 차이도 만료 판단에 영향을 줄 수 있습니다.

증상만 보고 HttpOnly나 Secure를 끄는 방법은 피하세요. 먼저 정상 요청과 실패 요청의 차이를 찾고 테스트 환경에서 작은 변경을 검증합니다. 로그인 HTML을 공유 캐시로 제공한다면 개인화와 쿠키 발급을 분리했는지도 확인합니다. 공개 HTML 캐시를 늘리는 작업과 로그인 쿠키 보호는 함께 설계해야 합니다.

7. 정상 로그인과 실패 로그인을 비교하기

테스트 계정으로 정상 로그인한 요청 한 건과 실패한 요청 한 건을 같은 순서로 기록합니다. 요청 주소, 호스트, 응답 코드와 쿠키 이름을 비교하고 비밀 값은 제외하세요. 쿠키가 발급되는 응답이 다르다면 먼저 로그인 처리 분기와 이동 과정을 확인합니다. 한 화면의 결과만 보는 것보다 흐름 비교가 설명하기 쉽습니다.

로그인 후 이동하는 주소가 www 유무나 서브도메인에 따라 달라지는지도 봅니다. Domain과 Path 적용 범위가 그 주소에 맞는지 확인하세요. 다만 공유 범위를 넓히면 다른 호스트에도 쿠키를 보내게 될 수 있으므로 필요 범위를 먼저 정합니다. 로그인을 고치기 위해 모든 서브도메인으로 무조건 확대하는 방식은 피합니다.

HTTPS 개발 환경과 HTTP 로컬 환경을 구분합니다. 쿠키가 저장됐는지뿐 아니라 브라우저가 왜 보내거나 보내지 않았는지 확인하는 편이 중요합니다. 로컬의 특별 처리와 운영 HTTPS 동작이 다를 수 있으므로 한 환경의 결과만 일반화하지 않습니다. 실제 적용할 서버에서 정상 흐름과 로그아웃 흐름을 모두 검사하세요.

로그아웃 때는 발급과 같은 이름, 호스트 범위와 경로를 사용하는지 대조합니다. 오래된 쿠키가 다른 범위에 남아 있으면 새 쿠키와 섞여 보일 수 있습니다. 테스트 환경에서 각각의 저장 항목을 확인하고 서비스가 실제 읽은 이름을 로그로 남기면 판단하기 쉽습니다. 로그에는 값 자체를 넣지 않아도 됩니다.

최종 기록은 발급 성공, 저장 성공, 전송 성공, 세션 검증 성공을 나누어 표시합니다. 이렇게 하면 어느 단계의 수정을 요청해야 하는지 분명해집니다. 문제를 고친 뒤 새로운 브라우저 프로필과 기존 프로필에서 모두 확인하면 오래된 값의 영향을 구분할 수 있습니다. 인증 속성을 끄는 방식보다 증거를 모아 필요한 부분만 수정하세요.

8. 따라 하는 예제

명령과 코드는 학습용입니다. 설명에 표시된 실행 환경을 구분하고 새 시험 폴더 또는 모의 입력으로 시작하세요.

예제 코드

from http.cookies import SimpleCookie
cookie = SimpleCookie()
cookie.load('session_token=demo; Path=/; Secure; HttpOnly; SameSite=Lax')
m = cookie['session_token']
print('Path:', m['path'])
print('Secure:', bool(m['secure']))
print('HttpOnly:', bool(m['httponly']))
print('SameSite:', m['samesite'])