사이드 프로젝트를 하기 전 브라우저에 대해 잘 알아야겠다고 생각해서
인증 및 인가와 관련된 쿠키, 세션 , JWT에 대해 공부했고
이번엔 브라우저 저장소와 관련된 내용을 공부해보려고 한다.
그 중 가장 자주 쓰이는 세션 스토리지와 로컬 스토리지에 대해 공부해보았다.
이전 공부한 내용에서 클라이언트 측에서 정보를 저장하기 위해서
Cookie
를 사용한다고 했었다.
Cookie
는 key ,value
의 쌍으로 이뤄진 자료구조로 주로 서버가 클라이언트 측으로 설정할 쿠키를
Set-Cookie
헤더와 함께 쿠키의 스코프를 지정해주는 프로퍼티 (Path , Domain
) 와 쿠키의 생명주기와 관련된 프로퍼티 (Max-Age , Expires
) 를 설정하여 보내주면
브라우저 측에서 헤더를 파싱하여 브라우저 측 쿠키 저장소에 데이터를 저장했었다.
쿠키는 Stateless
한 통신 속에서 클라이언트의 정보를 기억하여 지속적으로 서버와 통신을 가능하게 해주는 유용한 자료구조이지만 몇 가지 한계점이 존재한다.
Size limiation
쿠키는 본질적으로 쿠키 별로 가질 수 있는 용량이 4KB
가량 밖에 되지 않는다.
이러한 사이즈의 제한으로 인해 쿠키는 단순한 몇 글자 미만의 문자열만 저장 할 수 있었다.
Performance Impact
쿠키는 스코프 프로퍼티에 따라 다르겠지만 본질적으로 HTTP
요청이 일어날 때 마다 서버 측으로 전달되도록 설계되었다.
네트워크 통신 속에서 불필요한 쿠키를 전송하는 경우는 데이터 전송 측에서의 오버헤드를 늘린다는 단점이 존재한다.
굳이 지속적 전송이 필요 없는 정보이지만 저장하기 위해 쿠키에 저장하는 행위는 올바르지 않다.
Security and Privacy Concerns
쿠키는 지속적으로 통신과 함께 전송되기 때문에 쿠키의 스코프를 올바르게 지정해주지 않는 경우
CSRF (cross-site-request-forgery)
와 같은 공격에 취약하다.
CSRF
란악의적인 의도를 가지고 사용자가 요청하지 않은 요청을 보내는 것이다.
직관적인 예시로 사용자가 사용하는 은행 사이트가url
을 통해 은행 계좌의 돈을 누군가에게 보낼 수 있고 , 요청에서 쿠키로 사용자의 정보만 인증된다면 전송이 된다고 생각해보자이 때 악의적인 의도를 가지고 사용자가 해커에게 돈을 보내는
url
을 클릭하게 만들면 쿠키는url
만 보고 쿠키를 보내기 때문에 사용자가 의도치 않던 송금이 이뤄지게 된다.
쿠키의 한계점 정리
쿠키는 기본적으로 작은 사이즈의 정보만 저장이 가능하다는 단점이 존재하고
통신마다 쿠키가 담겨 보내지기 때문에 보안 측면에서 치명적인 단점이 존재한다.
Web Stroage
웹 스토리지는 브라우저가 클라이언트의 메모리나 디스크를 이용하여 정보를 저장하는 스토리지이다.
개발자도구 -> 어플리케이션 영역에 보면 Storage
영역에 다양한 스토리지 등이 존재하는 모습을 볼 수 있다.
Web Storage
의 장점웹 스토리지는 기본적으로 쿠키보다 더 많은 양의 정보를 저장하는 것이 가능하다.
브라우저마다 다르지만 최소
5MB
이상의 정보를 저장하는게 가능하다.
이렇게 많은 용량이 저장 가능하기 때문에 웹 스토리지에서는 {...}
형태로 이뤄진 아주 긴 문자열도 저장이 가능하여
웹 스토리지에는 객체나 배열 등을 저장하는 것이 가능하다.
하지만 객체나 배열 타입을 유지하며 저장되는 것이 아니다. 저장 할 때는 문자열 형태로 저장해야 하며 불러올 때는
JSON.parse()
를 통해 객체 형태로 받아와야 한다.
Web storage
에 저장된 정보는 쿠키와 다르게 통신 때 마다 자동으로 전송되는 것이 아닌 클라이언트가 직접 호출하여 조작한다.
이러한 점은 클라이언트와 서버 간의 오버헤드를 줄일 수가 있을 뿐 더러
CSRF
와 같은 공격에서도 안전하기에 안전하게 정보를 보관하고 있는 것이 가능하다.
쿠키는 서버 측에서 보내주는 생명 주기 프로퍼티에 따라 생명주기를 관리해야 하기에 복잡한 면이 존재했지만
웹 스토리지는 Session Storage
는 탭 별로 세션이 유지되는 동안에만 , Local Storage
는 영구적으로 데이터를 저장하게 함으로서
저장되는 정보의 생명주기를 간소화 하여 이용이 쉽게 만들었다.
Session Storage
와 Local Storage
Session Storage
와 Local Storage
의 스코프두 스토리지의 스코프는 공통점과 차이점이 존재한다.
우선 공통점으로 저장소의 스코프는 항상 도메인과 브라우저를 기준으로 나뉜다는 것이다.
예를 들어 도메인이 http://www.naver.com
에서 저장소에 정보를 저장했다면
브라우저가 http://www.naver.com
에서 호스팅 됐을 때만 저장된 정보를 사용 , 조회 하는 것이 가능하다.
만약 http://www.daum.net
과 같이 도메인이 변경되거나 https://www.naver.com
처럼 프로토콜이 변경된 경우에는 다른 도메인으로 인지하여
다른 스토리지를 가지게 된다.
추가로 브라우저 별로 스토리지의 스코프가 다르기 때문에 구글 크롬에서 저장된 스토리지는
파이어폭스의 스토리지에서는 조회가 불가능하다.
차이점으로 Session Storage
의 스코프는 탭 별로 , Local Storage
는 단순히 브라우저 별로 나뉜다는 것이다.
Session Storage
에서 Session
이 유지되고 있다는 것을 탭 별로까지 세부적으로 나뉘어
더욱 독립적인 공간을 구성하고
이를 통해 탭 별로 저장 할 수 있는 임시적인 정보를 저장하는 역할을 훌륭하게 수행하도록 설계되었다.
Local Storage
는 브라우저 별로만 스코프를 가지게 하여 여러 탭 별로 스토리지를 공유하는 것이 가능하다. (동일한 도메인이라면)
이를 통해 Local Storage
는 비교적 생명주기가 길거나 탭 별로 공유 해야 하는 정보를 저장하는 역할을 훌륭하게 수행한다.
Session Storage
와 Local Storage
의 LifeCycle
Session Storage
에 저장된 정보는 Session
이 종료되는 순간 라이프사이클이 종료되며
Local Storage
는 자바스크립트나 개발자 도구를 통해 제거하지 않는 이상 영구적으로 저장된다.
Session
이란Session Storage
는 기본적으로 두 호스트간 Session
이 유지되는 동안에만 정보를 저장하고 세션이 종료되면 정보를 휘발시킨다.
이전 챕터에서 세션을 이용한 인가를 공부했기 때문에
아 ~ 세션이란 두 호스트 간 (클라이언트와 서버)의 연결 상태를 의미하는구나 ~
라고 생각 할 수도 있지만 Session Storage
에서는 세션을 연결 상태 뿐이 아니라
브라우저 별 , 탭별까지 나눠서 생각하기 때문에 브라우저가 종료 되거나 , 탭이 종료되는 순간 세션이 종료 된 것으로 간주한다.
Session Storage , Local Storage
정리특징 | 세션 스토리지 | 로컬 스토리지 |
---|---|---|
범위 분할 | 탭 별 | 브라우저 별 |
사용 사례 | 각 탭별 임시 정보 저장 | 장기간 생명 주기를 가지는 정보 저장, 탭 간 공유 (동일 도메인) |
생명 주기 | 세션 종료시 종료: 브라우저 또는 탭 닫기 | 수동으로 제거되지 않는 한 영구적으로 저장 |
세션의 정의 |
세션 스토리지에서 세션은 브라우저 또는 탭을 닫을 때 종료된다. 클라이언트와 서버 사이의 활성 연결 상태로 간주되지만, 각 브라우저와 탭별로 별도로 구분된다. |
Session Storage , Session Storage
다루기window
객체는 두 스토리지에 접근 가능 하도록
Storage
객체를 이용하여 window.localStorage
, window.session Storage
프로퍼티를 제공한다.
기본적으로
window
를 통해 제공되는 전역프로퍼티기 때문에window
를 제외하고 사용하는 것이 가능하다.
Storage
객체는 length
프로퍼티와 스토리지를 조작 할 수 있는 다양한 메소드 등을 제공한다.
기본적으로 Storage
는 key ,value
형태로 값을 저장한다는 점에서 Cookie
와 같지만
더 많은 용량을 저장하는 것이 가능하기 때문에 복잡하고 큰 객체를 저장하는 것도 가능하다.
하지만 여전히 키와 밸류 값으로 저장해야 한다는 점은 동일하다.
setItem
과 removeItem
setItem(key,value)
setItem
은 key , value
값을 이용해 스토리지에 값을 저장하는 것이 가능하다.
기본적으로 지원하는 key , value
의 데이터타입은 문자열이기 때문에
key
값으로 문자열이 아닌 값을 저장하는 경우 문자열로 형 변환하여 저장한다.
value
값 또한 문자열만 저장하는 것이 가능하다.
만약 객체를 저장하면 [object Object]
라는 문자열 형태로 저장된다.
그렇기 때문에 객체를 저장하기 위해선 항상 JSON.strantify
를 이용해 직렬화 해줘야한다.
Storage
도 Object
의 프로토타입이기 때문에 Object
와 동일한 특성들이 많다.
위에서 보았듯 Storage
객체는 동일한 key
값을 허용하지 않는다.
또한 들어오는 정보들의 순서를 보장하지 않는다.
그냥 랜덤입니다요 ㅋ
removeItem(key)
removeItem
은 key
값을 이용해 스토리지에 저장된 데이터를 제거하는 것이 가능하다.
이 또한 문자열로 자동으로 형변환이 가능하다.
만약 존재하지 않는 키를 입력해도 오류가 발생하지 않고 아무런 일도 일어나지 않는다.
getItem(key)
getItem
은 키 값을 이용해 저장된 값을 가져오는 것이 가능하다.
존재하는 키 를 입력할 경우엔 저장된 값을 , 존재하지 않는 값을 입력하는 경우엔 null
객체를 반환한다.
만약 객체 형태로 저장된 값을 불러오고 싶다면 JSON.parse()
를 이용해 가져오자
clear()
clear()
는 시원하게 스토리지에 저장된 값을 모두 제거한다.