쿠키와 세션은 왜 사용되는가

HTTP 특징

HTTP는 기본적으로 무상태, 비연결성 프로토콜이다. 따라서 사용자가 로그인을 하거나, 장바구니에 물건을 담았더라도 다음 요청에는 어떤 로그인을 진행했는지, 장바구니에 어떤 물건을 담았는지 서버는 알 수가 없다. 이러한 제약을 극복하기 위해 쿠키와 세션이 사용된다.

 

비열결성과 무상태성이란

서버와 client가 요청과 응답을 주고받으면 연결이 끊어지게(connectionless) 되기 때문에 서버에서는 요청자의 이전 상태를 기억하지 못하게 되는데 이를 무상태라고 합니다.

 

이러한 장점은 서버에서 자원 낭비를 하지 않기 때문에 대규모 처리에 유용하게 됩니다.

쿠키

쿠키는 Client의 상태를 기억하기 위해서 사용된다. 쿠키는 Client에서 정보가 관리되기 때문에 보안에 취약하다. 이 쿠키에 값을 넣어주기 위해서는 서버에서 Set-cookies 필드에 값을 넣어주게 된다. 

 

또한 client에서 저장된 쿠키 정보를 서버로 보내기 위해서 헤더의 Cookies 필드를 이용해서 값을 전송한다.

형식

쿠키는 "key=value;" 로 이루어져 있다.

 

어떤 필드가 있을까?

Expires, max-age

Expires, max-age의 경우는 쿠키의 만료일을 설정하기 위한 필드입니다. expires의 경우는 GMT 형식이 되고, max-age 같은 경우는 초 단위로 설정되게 됩니다.

두 값이 동시에 설정되게 되면 max-age가 우선권을 가지게 됩니다.

 

만료가 없으면 영속쿠키와 비영속 쿠키로 나뉘게 됩니다. 영속쿠키는 브라우저가 종료될 때까지 남아있게 되고, 비영속 쿠키의 경우 쿠키 설정 시간에 따라 만료됩니다.

 

Path

이 경로를 포함한 path에서만 쿠키에 접근하도록 하기 위해서 사용됩니다. 보통은 루트를 지정하게 되는데 로그인을 하면 도메인의 하위 경로에서 보통은 모두 쿠키 정보가 필요하기 때문입니다.

 

Domain

쿠키의 도메인을 제한하는 데 사용됩니다. 이 설정은 쿠키가 특정 도메인 또는 그 하위 도메인에서만 사용되도록 하여 보안과 개인정보 보호를 강화하는 데 도움을 줍니다.

 

도메인 미지정 시 (명시적으로 설정하지 않은 경우):

• 도메인: example.com
• 설정: Domain=example.com

이 경우, example.com 및 모든 하위 도메인(예: subdomain.example.com, another.subdomain.example.com)은 쿠키를 공유할 수 있습니다. 그러나 anotherdomain.com 또는 다른 도메인에서는 이 쿠키에 접근할 수 없습니다.

 

도메인 명시 시:

• 도메인: sub.example.com
• 설정: Domain=sub.example.com

이 경우, sub.example.com 도메인과 그 하위 도메인(예: child.sub.example.com)만 쿠키에 접근할 수 있습니다. sub2.example.com 또는 다른 도메인에서는 이 쿠키에 접근할 수 없습니다.

 

Secure

이 설정은 HTTPS 프로토콜을 사용하는 웹 사이트에서만 쿠키를 전송하도록 강제하여 보안을 강화하는 역할을 합니다.

 

예를 들어, 로그인 세션을 유지하는 쿠키가 있을 경우, 이 쿠키에 "Secure" 속성을 설정하면 사용자의 로그인 정보가 안전한 방식으로 전송되고 저장될 수 있습니다. 따라서 중간자 공격과 같은 보안 위협으로부터 사용자 데이터를 보호할 수 있습니다.

 

HttpOnly

쿠키가 클라이언트 측 JavaScript를 통해 접근되는 것을 방지하는 데 사용됩니다. 일반적으로 쿠키는 JavaScript를 통해 접근할 수 있지만 이 설정을 있으면 JavaScript를 통해서 쿠키 값을 탈취하거나 조작할 수 없습니다.

 

예를 들어, 사용자의 인증 상태를 유지하는 쿠키가 있을 경우, 이 쿠키에 "HttpOnly" 속성을 설정하면, 클라이언트 측 JavaScript를 통해 이 쿠키의 값을 읽거나 조작하는 시도가 막히게 됩니다. 이로 인해 악의적인 공격자들이 사용자의 세션을 탈취하여 무단으로

로그인 상태를 변경하는 것을 예방할 수 있습니다.

 

구글에서 발급받은 쿠키 해설

__Secure-1PSIDCC=AKEyXzXz-0OZEV1K1zce89bEholeVJaFhxC-Bqib5VZj016ZgumWpegqQrZXoGqEytRPljUPedDS; expires=Tue, 24-Jun-2025 01:28:36 GMT; path=/; domain=.google.com; Secure; HttpOnly; priority=high

이 설정은 구글에서 보내주는 쿠키 설정입니다. expires를 통해서 쿠키 만료일을 설정하고 HTTPONYL 설정으로 js를 통해서 쿠키 설정을 건드리지 못하게 했고, 도메인을 설정을 통해서 하위 도메인까지 쿠키를 이용할 수 있도록 했습니다.

쿠키에 민감한 정보를 저장해도 될까?

쿠키는 생성되면 매 요청 시마다 헤더에 넣어서 서버로 전달되기 때문에 네트워크의 오버헤드를 유발할 수 있게 된다. 따라서 쿠키의 데이터는 4kb로 제한이 되어있다.

 

또한, 쿠키는 클라이언트에 저장되기 때문에 악의적인 사용자가 강제로 쿠키 설정을 값을 변경할 수 있게 된다. 따라서 쿠키에는 민감한 정보는 저장되면 안 된다.  

 

 

세션

세션도 쿠키와 비슷하게 상태정보를 저장하기 위해서 사용된다. 쿠키와의 다른 점은 서버 쪽에 저장되기 때문에 보안 측면에서 유리해진다.

세션 생성 과정

 

세션은 어떻게 생성될까?

처음, 사용자가 HTTP 요청의 Body에 인증 정보 (유저이름이나 패스워드 같은 것들)을 실어 서버로 보낸다. 서버에서는 해당 인증정보가 유효하면 사용자와 데이터를 식별하는 Session ID를 생성한다. 생성된 Session ID는 응답의 Set-Cookie 헤더에 생성된 세션 아이디를 실어 보내진다.

 

클라이언트는 해당 세션 아이디를 쿠키에 저장하고, 매 요청마다 세션 아이디를 Cookie 헤더에 실어 전송한다. 서버는 전달받은 세션 아이디를 통해 해당 요청의 송신자가 누구인지 식별할 수 있다.

세션 정보는 어디에 저장될까?

일반적으로 생성된 세션 데이터는 서버의 메모리에 저장된다. 하지만 로드 밸런싱등의 이유로 서버를 수평 확장(Scale Out) 하는 경우가 많을 것이다. 이런 경우 최초 세션이 생성된 서버와 그 이후의 요청을 받은 서버가 다른 경우 세션이 불일치하는 문제가 발생할 것이다.

 

이런 문제를 해결하기 위해 Key-Value로 저장되는 세션 특성상 Redis에 세션 ID를 저장하는 것이 일반적이다.

 

 

 

장바구니 유지 쿠키가 맞을까 세션이 맞을까?

결론적으로 세션을 사용해야 합니다. 그 이유는 다음과 같이 요약될 수 있는데 

 

1. 쿠키에 저장되면 다른 단말기에서 같은 정보로 접속했을 때 장바구니 유지가 불가능하게 됩니다. 왜냐하면 로컬스토리즈에 저장되기 때문입니다. 하지만 세션을 사용하게 되면 서버에 정보가 저장되기 때문에 어느 단말에서 접속하든 장바구니를 유지할 수 있게 됩니다.

 

2. 쿠키에는 보낼 수 있는 데이터 크기에 제한이 있어서 많은 장바구니 아이템을 저장하기에 한계가 있을 수 있습니다.