데이터와 보안 ·

쿠키와 세션과 브라우저 저장소를 보관함 위치로 구분하기

먼저 답부터

쿠키는 브라우저가 보관하며 조건에 맞는 서버 요청에 함께 보낼 수 있는 작은 값이고, 세션은 보통 서버가 로그인 상태를 보관하고 쿠키에는 연결용 식별자만 두는 방식입니다. localStorage는 같은 출처의 브라우저에 남지만 요청에 자동 첨부되지 않으므로 화면 설정에는 쓸 수 있어도 비밀키 저장소로 보면 안 됩니다.

쿠키와 세션과 브라우저 저장소를 보관함 위치로 구분하기 대표 이미지

로그인을 했는데 새로고침하자 풀리거나, 로그아웃했는데 다른 탭에서는 여전히 화면이 열리는 일이 있습니다. AI에게 물으면 쿠키, 세션, localStorage라는 말이 한꺼번에 나옵니다. 세 가지 모두 상태를 기억하는 데 쓰이지만 저장 위치와 서버로 전달되는 방식이 다릅니다.

카페에 비유하면 쿠키는 손님이 들고 다니는 번호표, 서버 세션은 카운터 안 주문 장부, localStorage는 손님 휴대전화의 개인 메모에 가깝습니다. 어디에 무엇을 적고 누가 읽는지를 나누면 로그인과 화면 설정 문제를 훨씬 안전하게 판단할 수 있습니다.

쿠키는 요청에 함께 갈 수 있는 작은 번호표다

HTTP 쿠키는 서버가 응답으로 설정하거나 브라우저 코드가 만들 수 있는 작은 이름과 값의 묶음입니다. 브라우저는 도메인, 경로, 만료, 보안 속성 같은 조건이 맞으면 이후 요청에 쿠키를 함께 보냅니다. 그래서 로그인 연결, 장바구니, 언어 설정 등에 쓰입니다.

쿠키에는 Secure, HttpOnly, SameSite 같은 속성이 있습니다. Secure는 HTTPS 요청에서만 전송하도록 제한하고, HttpOnly는 브라우저 JavaScript가 읽지 못하게 도우며, SameSite는 다른 사이트에서 시작된 요청에 쿠키가 붙는 범위를 조절합니다. 이 속성은 위험을 줄이지만 잘못된 권한 설계를 대신하지 않습니다.

  • 로그인 쿠키는 HTTPS에서만 전송하게 합니다.
  • JavaScript가 읽을 필요 없는 세션 쿠키에는 HttpOnly를 검토합니다.
  • SameSite 정책을 실제 로그인 흐름에 맞게 정합니다.
  • 만료 시간을 목적보다 길게 두지 않습니다.
  • 로그아웃 때 서버 상태와 쿠키를 함께 끝냅니다.

세션은 서버가 기억하는 로그인 장부다

세션은 여러 요청 사이에서 같은 사용자의 상태를 이어 가는 방식입니다. 흔한 서버 세션 방식에서는 서버가 로그인 정보와 권한을 보관하고, 브라우저 쿠키에는 긴 개인정보 대신 임의의 세션 식별자만 둡니다. 브라우저가 번호표를 보여 주면 서버가 카운터 장부에서 해당 주문을 찾는 모습과 같습니다.

세션 식별자가 탈취되면 다른 사람이 로그인 상태를 가로챌 수 있습니다. 따라서 예측하기 어렵게 만들고, HTTPS와 안전한 쿠키 속성을 쓰며, 로그아웃과 비밀번호 변경 때 무효화해야 합니다. 서버는 식별자를 받았다는 이유만으로 모든 행동을 허용하지 않고 요청마다 현재 권한을 확인합니다.

localStorage는 같은 출처의 브라우저 메모다

Web Storage API는 브라우저에서 키와 값 형태로 자료를 보관하는 기능입니다. localStorage는 브라우저를 닫아도 남을 수 있고, sessionStorage는 페이지 세션 단위로 분리됩니다. 여기서 세션 스토리지는 서버 세션과 이름이 비슷하지만 다른 기능입니다.

localStorage 값은 HTTP 요청에 자동으로 붙지 않습니다. 하지만 같은 출처에서 실행되는 JavaScript가 읽을 수 있으므로 악성 스크립트가 들어오면 노출될 수 있습니다. 테마, 접은 메뉴, 임시 초안처럼 유출돼도 피해가 작은 설정에는 편리하지만 API 비밀키, 비밀번호, 카드번호를 보관하는 금고가 아닙니다.

localStorage.setItem("theme", "dark");
const theme = localStorage.getItem("theme");
localStorage.removeItem("theme");

이 예시는 theme이라는 화면 설정을 저장하고 읽고 지웁니다. 값은 문자열로 저장되므로 객체를 다룰 때는 변환 규칙과 실패 처리를 정해야 합니다. 저장 공간이 가득 차거나 사용자가 차단·삭제할 수도 있으므로 중요한 원본 데이터로 믿어서는 안 됩니다.

같은 출처라는 경계가 저장소를 나눈다

출처는 프로토콜, 호스트, 포트의 조합으로 웹의 보안 경계를 구분하는 기준입니다. https://shop.example.comhttp://shop.example.com은 프로토콜이 달라 같은 저장 공간으로 보지 않을 수 있습니다. 서브도메인과 포트 차이도 영향을 줍니다.

쿠키는 Domain과 Path 설정에 따라 적용 범위를 조절할 수 있고, Web Storage는 문서의 출처 단위로 나뉩니다. "같은 회사 사이트"라는 사람의 판단과 브라우저의 출처 판단은 다를 수 있습니다. 개발 주소와 공개 주소에서 로그인 상태가 따로 보이는 이유도 여기서 찾을 수 있습니다.

개발자 도구에서는 값보다 범위를 먼저 본다

브라우저 개발자 도구의 Application 또는 Storage 화면에서 쿠키와 localStorage를 볼 수 있습니다. 문제를 조사할 때는 값을 복사해 공유하기보다 어느 도메인에 어떤 이름이 있고 만료와 보안 속성이 어떻게 설정됐는지 봅니다. 세션 식별자와 토큰 자체는 가려야 합니다.

로그아웃 오류라면 쿠키만 지워졌는지, 서버 세션도 무효화됐는지, 다른 탭의 화면이 서버에서 다시 권한을 확인하는지 살펴봅니다. 화면에서 메뉴를 숨겼다고 권한이 사라지는 것은 아닙니다. 서버가 보호된 요청을 거절해야 실제 로그아웃 경계가 완성됩니다.

오늘 바로 해볼 작은 실습

  1. 로그인하지 않은 공개 사이트를 열고 개발자 도구의 Storage 화면으로 갑니다.
  2. Cookies와 Local Storage에 어떤 이름이 있는지만 적고 값은 복사하지 않습니다.
  3. 콘솔에서 localStorage.setItem("practice-theme", "dark")를 실행합니다.
  4. Storage 화면에서 새 항목을 확인하고 페이지를 새로고침합니다.
  5. localStorage.removeItem("practice-theme")로 연습 값을 지웁니다.
  6. 쿠키와 localStorage 중 요청에 자동 첨부될 수 있는 쪽을 말로 설명합니다.

다른 사람의 컴퓨터나 실제 결제·업무 사이트에서는 저장 값을 임의로 바꾸지 마세요. 세션 식별자, 인증 토큰, API 키를 화면 캡처나 AI 대화에 붙여 넣지 않습니다. 뜻을 모르는 쿠키를 한꺼번에 삭제하면 로그인과 임시 작업이 사라질 수 있으므로 대상과 복구 영향을 설명할 수 있을 때만 변경합니다.

확인한 자료