보안: 어떤 신뢰되지 않은 사이트에서 브라우저에 저장된 클라이언트의 정보(쿠키)를 가지고 해당 쿠키를 발급한 서버로 악의적 목적으로 요청을 보내어 응답 결과를 탈취하거나, API를 악용, 남용하는 사례 등을 막기 위해 필요
예를 들어 착한 닷컴 접속 후 로그인 -> 로그인 유지(아이디, 비번) 위한 토큰 정보 브라우저에 저장
이후 알 수 없는 나쁜 닷컴에 접속 -> HTML, CSS, JS 코드가 유저의 브라우저에서 동작함 -> 해당 코드가 브라우저의 정보를 가지고 어떤 행동을 할 지 알 수 없음 -> 인증정보를 가지고 착한 닷컴에 요청을 보내서, 응답 정보를 나쁜 닷컴의 서버가 탈취, 이와 같이 착한 닷컴 API를 악용할 수 있음
브라우저는 이를 방지하기 위해 Same-Origin Policy를 고수
동일한 출처, 똑같은 URL끼리만 API 이용 등 접근이 가능하도록 함
Cross-Origin Resource Sharing: 다른 출처간에 리소스를 공유할 수 있도록 하는 것, 여기서 출처는 보내고 받는 각각의 위치 즉 웹사이트랑 API의 주소를 가리키며, 리소스는 주고받는 데이터를 가리킴. 예를 들어 내가 구축한 웹사이트와 네이버 API 간 데이터를 주고 받을 수 있도록 허용하는 것
이전에는 서로 다른 출처끼리 요청을 주고받는 건 안되는 게 기본값이었음, 브라우저에서 애초에 금지, 하지만 웹생태계가 다양해지면서 여러 서비스들간 보다 자유롭게 데이터를 주고 받을 필요성이 커짐, 따라서 이걸 "합의된 출처들간에 합법적으로 허용해주기 위해" 어떠 기준을 충족시키면 리소스 공유가 가능하도록 만들어진 메커니즘이 CORS.
어떻게 출처들을 허용하는가?
요청을 받는 백엔드(Spring, Django)에서 요청을 허락할 다른 출처들을 미리 명시해둠. CORS 옵션을 추가하고, 허용할 사이트들을 적어주면, 지정한 사이트에서는 이 서버로 얼마든지 HTTP 요청을 보낼 수 있음. 아무나 보낼 수 있는 요청의 경우 와일드카드를 이용해 모두 허용, 카카오 API를 이용할 때 우리가 kakao developers에 도메인을 등록해주는 것도 이와 같은 이유
브라우저는 다른 출처로의 요청을 보낼 때 요청에 Origin이라는 header를 추가, 요청을 받은 서버는 응답 헤더에 지정된 Access-Control-Allow-Origin 정보를 실어서 보냄, 만약 내 사이트 주소가 요청 서버에 등록된 사이트라면 이 정보에 내 사이트 주소도 담겨 있음. 크롬에서 Origin과 응답 데이터를 비교해서 현재 사이트가 있다면 안전한 요청으로 간주하고 응답데이터를 정상으로 수신함, 만약 허용되지 않은 origin의 요청이라면 응답 데이터를 사용하지 않고 CORS 에러를 띄움.
토큰 등 사용자 식별 정보가 담긴 요청에 대해서는 보다 엄격한 기준을 적용함. 일단 보내는 측에서는 요청의 옵션에 credentials 항목을 true로 세팅, 받는 쪽에서도 아무 출처나 다 허용하는 와일드카드가 아니라 보내는 쪽의 출처(웹피이지 주소)를 정확히 명시한 다음 Access-Control-Allow-Credentials 항목을 true로 맞춰줘야 함
GET, POST와 같은 simple request와 달리 PUL이나 DELETE와 같은 요청들은 본 요청을 보내기 전에 Prefligt을 보내서 본 요청이 안전한지 확인하고 허락이 떨어져야 요청을 보낼 수 있음. 서버의 데이터를 변경할 가능성이 있는 요청이기 때문에 요청 자체를 보내기 전에 먼저 허용 여부를 검증함.
출처: 얄팍한 코딩사전
sessionStorage는 클라이언트 측의 웹 브라우저에서 사용하는 웹 스토리지 메커니즘 중 하나인 sessionStorage에 데이터를 저장하는데 사용됩니다. 이것은 서버 세션과는 완전히 별개
sessionStorage.setItem: 클라이언트 측에서만 데이터를 유지하며, 브라우저의 세션 동안만 데이터 유지, 새로고침이나 브라우저를 닫으면 데이터가 손실
서버 세션: 서버 측에서 유지되며, 브라우저와는 독립적으로 서버의 상태를 저장합니다. 사용자가 로그인하거나 세션을 시작하면 서버는 해당 세션을 식별하는 정보를 클라이언트에게 부여하고, 이를 사용하여 세션을 관리, 브라우저를 닫아도 세션은 서버에 유지
서버가 뭔가를 기억하지 않고 그냥 토큰을 발급
HEADER, PAYLOAD, SIGNATURE 부분으로 나뉜 JWT 토큰
BASE64로 인코딩 하면 JOSN 형식으로 여러 정보가 들어 있음
메모리나 DB 등에 정보를 저장할 필요가 없음
Header에는 type(토큰의 타입, JWT)과 alg(algorithm, hs256.. 등 암호화 방식)
alg에는 signature(서명값)을 만든 알고리즘이 저장되어 있음
header, payload, 서버에 저장한 암호화 알고리즘 해석값을 이용하면 서명값을 추출할 수 있음
결점