Set-Cookie와 Cookie는 전송 방향이 어떻게 다를까

Set-Cookie는 서버 응답, Cookie는 이후 요청에서 읽습니다

Set-Cookie는 서버가 사용자 에이전트에 쿠키를 보내는 응답 헤더입니다. 이후 조건이 맞으면 요청에 쿠키가 다시 전달됩니다. 응답에 설정 헤더가 있었다는 사실, 브라우저가 저장한 사실, 다음 요청에 보낸 사실을 각각 확인해야 합니다. 브라우저 프런트엔드 JavaScript는 Set-Cookie 응답 헤더에 직접 접근할 수 없다는 점도 구분합니다. 근거: MDN Set-Cookie, 2026-11-04.

근거: MDN Set-Cookie · 2026-11-04 확인

로그인 직후만 풀리는 가상 증상을 세 단계로 봅니다

가상의 테스트 로그인이 성공했는데 다음 화면에서 다시 로그인 안내가 나온다면 먼저 응답에 설정 안내가 있었는지 봅니다. 다음으로 브라우저 저장 상태와 차단 이유, 마지막으로 다음 요청에 쿠키가 포함되는지 확인합니다. 이 순서가 저장 실패와 전송 범위 문제를 나누는 데 도움이 됩니다. 실제 세션 값은 화면 공유·명령 기록에 복사하지 않으며 테스트 계정만 사용합니다.

근거: MDN Set-Cookie · 2026-11-04 확인

속성은 각각 다른 조건을 제어합니다

Domain·Path는 적용 범위, 만료 관련 속성은 수명, Secure는 보안 전송 조건, HttpOnly는 JavaScript 접근 제한과 관련됩니다. HttpOnly여도 JavaScript가 시작한 요청에 쿠키가 전송될 수 있어 스크립트에서 값을 못 읽는 것과 서버에 안 가는 것은 다릅니다. SameSite도 요청 맥락을 다루므로 어떤 속성을 빼면 해결된다는 단순 처방보다 공식 규칙과 실제 사이트 관계를 확인합니다.

근거: MDN Set-Cookie · 2026-11-04 확인

서로 다른 주소·시간·브라우저 정책을 대조합니다

로그인 응답과 후속 요청의 호스트·경로·HTTPS 여부·시각을 적고 설정 속성과 비교합니다. 브라우저 정책이나 차단 안내가 있다면 그 사유를 확인합니다. 여러 쿠키를 보낼 때는 별도의 Set-Cookie 헤더를 사용하는 규칙도 고려합니다. 보안 속성을 무작정 제거하거나 세션 값을 URL에 넣어 우회하지 않습니다. 이 글은 실제 설정을 변경한 결과가 아닙니다.

성공은 필요한 요청에서 정상 세션이 유지되는 것입니다

허가된 테스트에서 후속 화면이 같은 계정을 올바르게 인식하고 종료·만료 조건도 의도대로 작동하는지 확인합니다. 저장 항목 한 줄이 보였다는 이유만으로 세션 검증 완료로 쓰지 않습니다. 해결되지 않으면 비밀 제거 속성·주소·차단 사유·요청ID를 지원에 전달합니다. Secure나 HttpOnly 하나만으로 모든 쿠키 보안이 완성된다고 보고하지 않습니다.

옆 문서로 이어가기