브라우저 저장소

Bonggus·2021년 10월 11일
1

브라우저공부

목록 보기
2/9
post-thumbnail

브라우저 저장소

  • 웹스토리지는 HTML5부터 제공되는 기능이다
  • 해당 할 수 있도록 제공하는 기능도메인과 관련된 특정 데이터를 클라이언트 웹브라우저에 저장
  • 쿠키와 비슷한 기능
  • 웹스토리지의 개념은 키/값 쌍으로 데이터를 저장하고, 키를 기반으로 데이터를 조회하는 패턴 (key/value Stroage 형태)
  • LocalStorage, SessionStroage가 있고, 데이터의 지속성의 차이가 있다.

브라우저 저장소가 필요한 이유

  • 쿠키와 브라우저 저장소는 모두 브라우저에 저장된다.

  • 쿠키는 브라우저 저장소가 등장하기 이전, 대표적인 브라우저 정보 저장소의 역할

  • 쿠키는 만료기간이 있는 key/value저장소

  • httponly 플래그로 자바스크립트에서 쓸 수 없게 막아둔 쿠키는 나오지 않는다.

  • 4KB용량 제한, 매 서버 요청마다 서버로 쿠키가 같이 전송

  • 요청시 서버로 쿠키를 전송하는 이유는 서버에게 '누가 요청을 했는가'를 알려주기 위함

  • '누가 요청을 했는가'를 알아야 서버는 정확한 정보를 전달할 수 있다

  • 그래서, 쿠키에 내 정보를 담아서 서버에 보내면 서버는 쿠키를 읽어서 내가 누군지 파악(요청보낸게 누구인지)

  • 쿠키는 처음부터 서버와 클라이언트 간의 지속적인 데이터 교환을 위해 만들어졌기 때문에 서버로 게속 전송된다.

  • 하지만, 4KB의 용량제한을 거의 다 채운 쿠키가 있다면, 요청할 때마다 기본 4KB의 데이터를 사용한다.

  • 필요하지 않는 정보도 계속 요청하게 되는 것인데, 즉 데이터의 낭비가 일어나게 된다.

  • 이러한 문제점을 Local, Session Stroage를 통해 해결 가능하다.

  • 웹 브라우저 저장소는 쿠키의 단점을 극복할 수 있다

    • 4KB 데이터 저장 제한
    • HTTP Request에 암호화 되지 않은 상태로 사용하기 때문에 보안에 취약
    • 쿠키는 모든 HTTP Request에 포함되어 있어 웹서비스에 영향을 줄 수 있다

Web Storage vs Cookie

  1. 쿠키는 매번 서버로 전송된다

    웹사이트에서 쿠키를 설정하면 이후 모든 웹요청은 쿠키정보를 포함해서 서버로 전송된다. 브라우저 저장소는 저정된 데이터가 클라이언트에 존재할 뿐 서버로 전송되지 않는다. 이는 네트워크 트래픽 비용을 줄여준다.

  1. 브라우저 저장소는 단순 문자열을 넘어 Script 객체정보를 저장할 수 있다

    문자열 기반 데이터 외에 체계적으로 구조화된 객체를 저장할 수 있다. 이는 개발 편의성을 제공해주는 장점이다. (브라우저 지원여부가 중요)

  1. 브라우저 저장소는 용량의 제한이 없다

    쿠키는 개수와 용량에 제한이 있다. 클라이언트에 최대 300개의 쿠키를 저장할 수 있다. 하나의 사이트(도메인)에는 최대 20개를 저장할 수 있고, 쿠키값은 최대 4KB로 제한된다.
    브라우저 저장소는 제한이 없다. 쿠키도 하위키를 이용하면 이러한 제한을 일부 해소 가능하다. 그러나 대용량으로 쿠키를 저장할 일은 없다

  1. 브라우저 저장소는 영구 데이터 저장이 가능

    쿠키는 만료일자를 지정하게 되어있어 언젠가 제거된다. 만약 만료일자를 지정하지 않으면 세션쿠키가 된다. 영구쿠키를 원하면 만료일자를 길게 설정하여 해결할 수 있다.

    브라우저 저장소는 만료일이 없다. 즉, 한번 저장한 데이터는 영구적으로 존재

  1. 세션쿠키 / 지속(영구) 쿠키

    세선쿠키: 활성 웹 브라우저 세션이 있는 기간동안 저장. 세션쿠키는 일반적으로 웹 브라우저를 닫을 때 삭제

    지속(영구)쿠키: 각 쿠키에 지정된 기간동안 또는 장치에서 쿠키를 수동으로 삭제할 때까지 장치에 남아있는 쿠키

브라우저 저장소의 종류

  1. Local Storage: 브라우저를 닫았다 열어도 계속 유지
  2. Session Storage: 브라우저가 열려있는 한 페이지를 새로고침해도 계속 유지된다. 하지만 브라우저를 닫으면 삭제된다
  • 둘의 큰 차이점은 데이터의 영구성

  • 둘 다 Window 객체 안에 들어있다.

  • Storage객체를 상속받기 때문에 공통적으로 존재.

  • 도메인별 용량제한이 있다(프로토콜, 호스트, 포트가 같으면 같은 스토리지를 공유)

  • 브라우저별, 기기별 용량제한이 다르지만 모바일 2.5MB, 데스크탑 5~10MB

  • 저장되는 데이터가 key/value 형태이고, 쿠키가 4KB인 것을 생각하면 큰 용량.

  • 50MB를 기본으로하는 indexedDB도 있다.

  • 기존 사용하던 쿠키/세션처럼 브라우저 저장소도 Local Storage, Session Storage를 제공한다

  • Session Storage 역시 브라우저에 저장된다. 하지만 생명주기가 서로 다른게 차이점.

세션(session)?

  • 쿠키는 방문자의 정보를 방문자의 컴퓨터 메모리에 저장한다

  • 세션은 방문자의 요청에 따른 정보를 웹서버가 세션아이디를 만들어 서비스가 돌아가고있는 서버에 저장한다

  • 즉 쿠키는 방문자가, 세션은 제품서버가 가지고 있는 정보

  • 쿠키와 달리 세션은 로그인 정보에 대한 보안이 더 좋다. 따라서 웹사이트에 방문해서 계속 접속을 유지할 때 이전의 접속 정보를 이용할 수 있는 방법으로 많이 사용한다.

  • 정보가 서버에있어서 보안은 더 좋지만, 사용자가 많아질수록 서버 메모리를 많이 차지하게 된다. (서버 과부하의 원인)

  • 세션도 쿠키처럼 만료일을 설정할 수 있지만, 브라우저가 종료되면 만료시간에 상관없이 삭제된다.

  • 쿠키는 서버에 요청시 세션보다 속도가 빠르다.

  • 세션은 정보가 서버에 있기 때문에 처리가 요구되어서 비교적 속도가 느린 편이다(쿠키에 비해)

  • 보통 쿠키와 세션의 차이를 말할 때는 저장위치와 보안적인 부분뿐만 아니라 라이프 사이클까지 말할 수 있어야 한다.

  • 쿠키는 브라우저를 종료해도 저장되어 있을 수 있다(사용자 컴퓨터 메모리에 저장되기 때문)

    • 세션은 서버에서 만료시간/날짜를 정해서 지워버릴 수 있고, 브라우저 종료시 저장된 데이터가 사라진다.
  • 쿠키/세션 vs 캐시?

    • 캐시는 이미지나 css,js 파일 등을 브라우저나 서버 앞 단에 저장해놓고 사용하는 것
    • 한번 캐시에 저장되면 브라우저를 참고하기 때문에 서버에서 변경이 되어도 사용자는 변경되지 않게 보일 수 있다
    • 이런 부분은 캐시를 지워주거나, 서버에서 클라이언트에 응답할때 Header에 캐시 만료시간을 명시함으로써 해결 가능
  • 세션 id
    - 클라이언트가 req를 보내면, 해당 서버의 엔진이 클라이언트에게 유일한 id를 부여한다. 이것이 세션id

Local Storage

  • 저장한 데이터를 명시적으로 지우지 않는 이상 영구적으로 보관 가능
  • 도메인마다 별도로 Local Storage가 생성된다.
  • 도메인만 같으면 전역적으로 공유가 가능
  • window 전역 객체의 LocalStorage라는 컬렉션을 통해 저장과 조회가 이루어진다.(window.localStorage)
  • Key/Value 순서대로 저장. 문자열로 저장.
  • 문자열, Boolean, 숫자, Null, undefined등을 저장할 수 있지만, 문자열로 변환된다.
localStorage.setItem(,); // 저장
localStorage.getItem(); // Read
localStorage.removeItem(); // Remove
localStorage.clear(); // Remove All

Session Storage

  • 브라우저를 닫으면 삭제된다.
  • 데이터의 지속성과 액세스 범위에 특수한 제한이 존재
  • 도메인별로 별도 생성
  • 같은 사이트의 같은 도메인이라도 브라우저가 다르면 서로 다른 영역이 된다
  • 브라우저 컨텍스트가 다르기 때문. Document를 표시하는 환경, 즉 브라우저가 불러운 웹페이지라고 생각하면 된다
  • Window 전역객체의 SessionStorage라는 컬렉션을 통해 저장과 조회가 이루어진다(window.sessionStorage).
  • clear, getItem, setItem, removeItem, key 등 메소드는 동일하다.

언제 사용 하는가?

보안문제

  • Local, Session Storage 모두 XSS(Cross-site Scripting)에 취약

  • XSS 공격은 스토리지 개체에서 데이터를 가져오고 저장된 데이터에 악성 스크립트를 추가하는데 사용될 수 있다.

  • 예를들어 타사 JS라이브러리를 사용하고, 저장소 개체를 추출하는 일부 스크립트가 삽입된 경우 저장소 데이터는 더 이상 안전하지 않다.

  • 따라서 민감한 데이터는 저장하지 않는 것이 좋다

    • 사용자 이름/비밀번호
    • 신용카드정보
    • JWT토큰
    • API키
    • 개인정보
    • 세션ID
    • 일부 데이터가 LocalStorage에 저자왿면 개발자는 사용자가 삭제할 때까지 데이터를 지울 수 없다. 따라서 세션이 종료된 후 데이터를 제거하려면 SessionStorage를 사용하는 것이 좋다

요약

  • 브라우저에 데이터를 저장하는 방법에는 Cookie와 브라우저 저장소(Web Storage)가 있다.

  • 쿠키와 브라우저저장소 모두 도메인과 관련된 데이터를 클라이언트 웹브라우저에 저장한다.

  • 둘다 도메인 단위로 접근이 제한된다.

  • A도메인에서 저정한 데이터는 B도메인에서 접근이 불가핟

  • 쿠키는 매번 서버로 전송되고 문자열만 저장이 가능하다

  • 용량에 제한이 있다

  • 만료 일자가 존재한다

  • 브라우저 저장소는 데이터를 클라이언트에만 저장한다

  • 서버로 전송하지 않는다

  • 문자열 외에도 구조화된 객체를 사용 가능해서 개발 편의성을 제공한다

  • 하나의 사이트에 저장할 수 있는 용량이 제한되어있지 않다

  • 한번 저장된 데이터는 영구적으로 저장된다

  • 브라우저 저장소는 Local, Session Stroage가 있다

  • LocalStorage는 저장한 데이터를 지우지않는한 영구적으로 보관된다

  • 도메인마다 별도로 LocalStorage가 생성된다

  • 도메인만 같다면 전역적으로 공유가 가능하다

  • 브라우저를 닫았다 열어도 지속

  • SessionStorage는 데이터의 지속성과 엑세스 범위에 특수한 제한이 존재한다

  • 도메인마다 별도로 생상된다. 하지만 같은 사이트의 도메인이라도 브라우저가 다르면 서로 다른 영역

  • 브라우저를 닫으면 사라진다.

출처

profile
프론트엔드

0개의 댓글