HTTP

HTTP 완벽 가이드 (11) : 클라이언트 식별과 쿠키

kchabin 2025. 3. 15. 13:17

draw io 링크

https://drive.google.com/file/d/1NZfjJ4QznXf5kasNnzXIFe3CnFZOHWG9/view?usp=sharing

 

11장.drawio

 

drive.google.com

 

클라이언트 식별과 쿠키

HTTP 특징

  • 무상태
  • 요청과 응답으로 통신

개인화된 서비스를 제공하고 싶은 웹 사이트들

  • 개별 인사
  • 사용자 맞춤 추천
  • 저장된 사용자 정보
  • 세션 추적
    • 무상태, 독립적으로 일어나는 각 요청 및 응답
    • 사용자와 사이트의 상호작용 → 상태를 남김(쇼핑몰 장바구니 기능)

사용자 식별 기술

  • 사용자 식별 관련 정보를 전달하는 HTTP 헤더
  • 클라이언트 IP 주소 추적
  • 사용자 로그인 인증
  • Fat URL - URL + 식별자
  • 식별 정보 유지 지속 쿠키

HTTP 헤더

헤더 이름 헤더 타입 설명

From 요청 사용자의 이메일 주소
User-Agent 요청 사용자의 브라우저
Referer 요청 사용자가 현재 링크를 타고 온 근원 페이지
Authorization 요청 사용자 이름과 비밀번호
Client-ip 확장(요청) 클라이언트의 IP 주소
X-Forwarded-For 확장(요청) 클라이언트의 IP 주소
Cookie 확장(요청) 서버가 생성한 ID 라벨
  • From - 악의적 서버의 스팸 메일 발송 문제 있음. 로봇/스파이더는 웹 마스터 항의를 받은 이메일 주소를 기술함
  • User-Agent - 사용자가 쓰고있는 브라우저의 이름과 버전정보, 운영체제 정보까지 포함하기도 함.
    • 특정 브라우저에서 잘 동작하도록 콘텐츠 최적화에 유용함.
    • 특정 사용자를 식별하는 데는 큰 도움이 되지 않음
  • Referer - 사용자가 현재 페이지로 유입하게 한 웹페이지의 URL
    • 사용자가 이전에 어떤 페이지를 방문했었는지는 알려줌.

⇒ 특정 사용자를 확실히 식별하기에는 부족함

클라이언트 IP 주소

사용자 식별에 IP 주소 사용

  • 사용자가 아닌, 사용자가 사용하는 컴퓨터를 가리킴
    • 여러 사용자가 같은 컴퓨터를 사용하면 특정 사용자 식별 불가능
  • 사용자 로그인시 ISP 동적 IP 주소 할당
    • 로그인한 시간에 따라 사용자는 매번 다른 주소를 받음
  • NAT 방화벽 - 실제 IP 주소를 방화벽 뒤로 숨김.
    • 내부에서 사용하는 하나의 방화벽 IP 주소로 변환
  • 프락시와 게이트웨이는 원 서버에 새로운 TCP 연결을 함.
    • 웹 서버는 클라이언트 대신 프락시의 IP 주소를 봄
    • Client-ip, X-Forwarded-For-HTTP : 프락시가 원본 IP 주소를 보존하려고 추가하는 확장 헤더
      • 모든 프락시가 이런 식으로 동작하진 않음.

사용자 로그인

로그인 요구 → 사용자에게 명시적으로 식별 요청 가능

웹 사이트에 사용자 이름을 전달하는 자체적 체계 존재

  • WWW-Authenticate, Authorization 헤더
  • 사이트 접근 전 로그인 요구 → 401 Login Required 응답 코드 전송
    • 사용자가 요청마다 로그인하지 않게 브라우저 대부분은 사이트에 대한 로그인 정보를 기억하여 사이트로 보내는 각 요청에 로그인 정보를 전달하게 됨

  • 서버는 사이트 접근 전 로그인을 요구한다.
    • 401 상태코드와 WWW-authenticate 헤더를 전송한다.
  • 사용자가 이름과 비밀번호를 입력하고 브라우저는 기존 요청을 다시 보내서 사용자 식별을 시도한다.
  • 이제 서버는 사용자의 식별정보를 안다
  • 이후 요청에 대해, 브라우저는 서버로부터 사용자 식별 정보를 요청받으면, 서버에서 오는 요청에 대해 자동으로 사용자 이름과 비밀번호를 포함한다.
    • 요청하지 않았을 때에도 전달
  • 요청마다 해당 사용자의 식별정보 토큰을 Authorization 헤더에 담아 서버로 전송, 한 세션이 진행되는 내내 그 사용자에 대한 식별을 유지한다.

단점 : 사이트를 옮겨다닐 때마다 각 사이트에 로그인 해야함.

  • 이름 선점, 비밀번호 규칙 차이 등

뚱뚱한 URL

사용자의 URL마다 버전을 기술하여 사용자를 식별하고 추적하는 웹 사이트

  • URL의 처음이나 끝에 어떤 상태정보를 추가해 확장
  • 사용자의 상태정보를 포함하고 있는 URL
  • 온라인 쇼핑몰을 돌아다니는 사용자에게 식별번호를 할당, 각 URL 뒤에 붙여서 사용자 추적

HTTP 트랜잭션을 하나의 ‘세션’ or ‘방문’으로 묶는 용도

  1. 처음 방문한 사용자에 대한 유일한 ID 생성
  2. 서버가 인식 → 클라이언트를 fat url로 리다이렉트 시킴
  3. fat url을 포함한 요청을 받으면, 사용자 아이디와 관련된 추가적인 정보(쇼핑카트,프로필 등)를 찾아서 밖으로 향하는 모든 하이퍼링크를 fat url로 바꿈

단점

  1. 못생긴 url - 사용자들에게 혼란을 줌
  2. 공유하지 못하는 url : 특정 사용자와 세션에 대한 상태정보 포함 → 개인정보를 공개하게됨
  3. 캐시를 사용할 수 없음 : URL이 달라지기 때문에 기존 캐시에 접근 불가능
  4. 서버 부하 가중 : fat url에 해당하는 html 페이지를 다시 그려야 함.
  5. 이탈 : 링크를 타고 다른 사이트로 이동하거나 특정 URL을 요청 → 의도치않게 해당 세션에서 ‘이탈’하게 됨
    1. 사전에 세션 정보가 추가된 링크만을 사용해야 fat url이 문제없이 동작함
    2. 이탈 시 초기화 후 처음부터 시작 ← 쇼핑 장바구니 등
  6. 세션 간 지속성의 부재 : 특정 Fat URL을 북마크하지 않는 이상, 로그아웃하면 모든 정보 유실

쿠키

  • 넷스케이프 최초 개발
  • 캐시 충돌 가능성 → 쿠키에 있는 내용물 캐싱하지 않음

타입

  • 세션 쿠키
    • 임시 쿠키
    • 사용자가 브라우저를 닫으면 삭제됨
  • 지속 쿠키
    • 디스크 저장 → 재시작 해도 남아있음.

사이트마다 다른 쿠키

쿠키가 수백, 수천 개 가능 but 두세개만 전송함.

  • 쿠키를 모두 전달하면 성능 저하
  • 대부분의 쿠키는 서버에 특화된 이름/값 쌍 포함, 대부분 사이트에서는 인식하지 않는 무의미한 값

광고 쿠키

  • 웹사이트와 협력업체의 광고계약
  • 광고들은 웹 사이트 자체의 일부인 것처럼 제작되고, 지속 쿠키를 만들어냄
  • 같은 광고사에서 제공하는 서로 다른 웹 사이트에 사용자가 방문하면, 브라우저는 앞서 만든 지속 쿠키를 다시 광고사 서버로 전송한다.
    • 지속 쿠키의 도메인이 같기 때문
  • Referer 헤더를 접목하여 사용자의 프로필과 웹 사이트를 사용하는 습관에 대한 방대한 데이터를 구축할 수 있음.
  • 최신 브라우저 개인정보 설정 기능 → 쿠키 사용 방식에 제약

쿠키 Domain 속성

서버는 응답 헤더에 Set-cookie 헤더의 domain 속성을 사용해 어떤 사이트가 그 쿠키를 읽을 수 있는지 제어할 수 있음

Set-cookie: user="mary17"; domain="example.com"
  • example.com으로 끝나는 사이트를 방문하면 Cookie: user=”mary17” 헤더가 항상 적용됨

path 속성

웹 사이트 일부에만 쿠키 적용

각각 쿠키를 별도로 갖는 두 개의 조직이 한 개의 웹 서버를 공유할 경우

Set-cookie: pref=compact; domain="example.com"; path=/autos/

사용자가 /autos/ 경로에 접근하면 쿠키를 두 가지 받게됨.

Cookie: user="mary17"
Cookie: pref=compact

쿠키 구성요소

Version 0 쿠키(넷스케이프)

  • Version 1 쿠키 → Version 0 쿠키의 확장, 널리 쓰이진 않음
  • 최초의 쿠키 명세
Set-Cookie: name=value [; expires=date] [; path=path] [; domain=domain] [; secure]
  • expires : 쿠키의 생명주기를 가리킴.
    • 요일, DD-MM-YY HH:MM:SS GMT
    • GMT만 사용가능
    • 쿠키에 Expires를 명시하지 않으면 사용자의 세션이 끝날 때 파기됨
  • domain
  • path
  • secure : HTTP가 SSL 보안 연결을 사용할 때만 쿠키 전송
    • client가 쿠키값을 변경할 수도 있음. → 쿠키 정보 변경 case
    • 클라이언트 개발할 때마다 기존 서버 쿠키를 받아서 행위등의 정보를 싣어서 서버에게 보낼 수 있음
    • secure 쿠키는 클라이언트에서 정보 변경 불가능
    • 개발할 땐 풀어놨다가, 운영 시에는 바꾸는 방식

버전 1 쿠키(RFC2965) 는 폐기되어 더 이상 지원되지 않음

  • 쿠키마다 그 목적을 설명하는 설명문이 있음
  • 파기 주기에 상관없이 브라우저가 닫히면 쿠키를 강제로 삭제할 수 있다.
  • Max-Age: 절대 날짜 값 대신에 초 단위 상대값으로 생명 주기를 결정할 수 있음
  • URL의 포트번호로도 쿠키를 제어할 수 있음.
  • 도메인, 포트, 경로 필터가 있으면 Cookie 헤더에 담겨 되돌려보냄
  • cookie2 = “Cookie2:” cookie-version : 호환되는 버전 번호

세션 추적

캐시

개인정보 유출, 이전 사용자의 쿠키를 다른 사용자에게 할당 등 문제로 쿠키는 캐시하지 않는 게 좋음

Cache-Control: no-cache="Set-Cookie"
  • 문서의 본문은 캐시하더라도 Set-Cookie 헤더는 제외해야함
    • 여러 사용자에게 보내게 되면, 사용자 추적에 실패함.
    • → 캐시는 공용인 경우가 많으니까 쿠키 헤더가 여러명에게 보내질 수 있다는건가?
  • 어떤 캐시는 응답을 저장하기 전에 Set-Cookie 헤더를 제거함 → 해당 헤더 정보가 없는 데이터를 받게 됨 → 문제 발생
    • 개선 방안 : 모든 요청마다 원 서버와 재검사해서 Set-Cookie 헤더 추가
Cache-Control: **must-revalidate, max-age=0**
  • 보수적인 캐시는 콘텐츠가 캐시 가능한 데이터여도 set-cookie 헤더가 있는 응답은 캐시하지않을 수 있음
  • 어떤 캐시는 쿠키헤더가 있는 이미지는 캐시하고, 텍스트는 캐시하지 않기도 함.

Cookie 헤더를 갖고 있는 요청을 주의해라

  • 요청 + 쿠키 = 결과 콘텐츠가 개인정보를 담고있을 수도 있다.
  • 위에서 말한 Set-Cookie 헤더가 포함된 이미지는 해도, 텍스트는 캐시하지 않는 경우에 속함.
  • 더 효율적인 방식 = 캐시 이미지에 파기 시간이 0인 cookie 헤더를 설정해서 매번 재검사하도록 강제함.

<aside> 💡

max-age : 문서의 최대 나이 정의 문서가 처음 생성된 이후~제공하기엔 더 이상 신선하지 않다고 간주될 때까지 경과한 시간의 합법적인 최댓값(초 단위)

</aside>

쿠키가 보안상으로 엄청나게 위험한 것은 아니다.

  • 쿠키 사용 비활성화, 로그 파일 분석으로 대체도 가능
  • 원격 DB에 개인 정보를 저장하고, 쿠키에 해당 데이터의 키 값을 저장하는 방식을 사용하면, 클라이언트와 서버 사이에 예민한 데이터가 오가는 것을 줄일 수 있다.

로그 파일을 분석해도 사용자의 브라우징 습관을 추적할 수 있다. 쿠키는 그것을 좀 더 편리하게 해주는 방식

jwt 토큰도 쿠키에 저장해서 많이 사용함.

  • 불변으로 만들어놓기도 하고
  • 쿠키에 저장하는건 굉장히 위험 → 세션 스토리지
    • 세션 스토리지 - 요청을 하면 세션이 하나 만들어짐(커넥션처럼)
      • 서블릿 → jsession-id
      • 브라우저가 닫히기 전까지 정보가 디스크에 유지됨
      • 세션 id마다 할당된 스토리지
      • 중요 정보는 넣지 않는다.
      • mid(my id) - 클라이언트에 세팅 ← 이것과 뭔가 더 조합
        • 쿠키를 탈취하더라도 안전하도록
    • 로컬 스토리지 - 쿠키와 비슷한 애. 로컬 디스크에 저장, 아무나 볼 수 있음.
      • 브라우저 내 파일에 저장

인증과 인가

  • 인증(Authentication)은 이 사람이 그 사람이 맞냐
  • 인가(Authorization)는 이 사람이 적법한 권한을 갖고 있는 유저인가.
    • 이 url에 보낼 수 있는가

프록시 서버나 api gateway ip가 서버로 올라감

  • 진짜 클라이언트 ip는 X-Forward-For로 알아냄
  • 특정 ip나 대역만 서버를 사용할 수 있도록
    • ex) 가맹점 외 ip 대역은 통과 시키지 못하도록 사전 차단
    • 중간에 프록시가 껴있으면 검사가 안됨

User-Agent

  • pc용 api, 모바일용 api 등 구분 가능

Referer

  • 어떤 화면으로부터 api가 호출되었는지

브라우저를 오픈할 때 세션이 만들어짐. → 세션 쿠키

  • user의 로그인한 키 세팅
  • 인증값, 보안적으로 필요, 일시적으로 저장해야하는 것들
  • 나 아닌 다른 유저가 세션 쿠키를 볼 수 없음.

지속 쿠키에는 사용자의 로그인 키 세팅 안함

  • 처리상태, user의 상태 정보 등을 저장

회원 탈퇴 정보는 서버. 클라이언트x

매번 재검사 → 서버에서 매번 다시 들고내려옴

쿠키를 http-response에 내려보는 테스트 해보기

  • secure 속성 설정

샌드박스

  • 안팎으로 제한된

회사에서 A.naver.com, B.naver.com 사용

  • CORS(Cross Origin Resource Sharing) : 어떤 도메인끼리는 CORS로 묶여있는 서버
    • 무상태
    • 요청과 응답으로 통신
    개인화된 서비스를 제공하고 싶은 웹 사이트들
    • 개별 인사
    • 사용자 맞춤 추천
    • 저장된 사용자 정보
    • 세션 추적
      • 무상태, 독립적으로 일어나는 각 요청 및 응답
      • 사용자와 사이트의 상호작용 → 상태를 남김(쇼핑몰 장바구니 기능)
    사용자 식별 기술
    • 사용자 식별 관련 정보를 전달하는 HTTP 헤더
    • 클라이언트 IP 주소 추적
    • 사용자 로그인 인증
    • Fat URL - URL + 식별자
    • 식별 정보 유지 지속 쿠키
    HTTP 헤더헤더 이름 헤더 타입 설명
    From 요청 사용자의 이메일 주소
    User-Agent 요청 사용자의 브라우저
    Referer 요청 사용자가 현재 링크를 타고 온 근원 페이지
    Authorization 요청 사용자 이름과 비밀번호
    Client-ip 확장(요청) 클라이언트의 IP 주소
    X-Forwarded-For 확장(요청) 클라이언트의 IP 주소
    Cookie 확장(요청) 서버가 생성한 ID 라벨
    • From - 악의적 서버의 스팸 메일 발송 문제 있음. 로봇/스파이더는 웹 마스터 항의를 받은 이메일 주소를 기술함
    • User-Agent - 사용자가 쓰고있는 브라우저의 이름과 버전정보, 운영체제 정보까지 포함하기도 함.
      • 특정 브라우저에서 잘 동작하도록 콘텐츠 최적화에 유용함.
      • 특정 사용자를 식별하는 데는 큰 도움이 되지 않음
    • Referer - 사용자가 현재 페이지로 유입하게 한 웹페이지의 URL
      • 사용자가 이전에 어떤 페이지를 방문했었는지는 알려줌.
    ⇒ 특정 사용자를 확실히 식별하기에는 부족함사용자 식별에 IP 주소 사용
    • 사용자가 아닌, 사용자가 사용하는 컴퓨터를 가리킴
      • 여러 사용자가 같은 컴퓨터를 사용하면 특정 사용자 식별 불가능
    • 사용자 로그인시 ISP 동적 IP 주소 할당
      • 로그인한 시간에 따라 사용자는 매번 다른 주소를 받음
    • NAT 방화벽 - 실제 IP 주소를 방화벽 뒤로 숨김.
      • 내부에서 사용하는 하나의 방화벽 IP 주소로 변환
    • 프락시와 게이트웨이는 원 서버에 새로운 TCP 연결을 함.
      • 웹 서버는 클라이언트 대신 프락시의 IP 주소를 봄
      • Client-ip, X-Forwarded-For-HTTP : 프락시가 원본 IP 주소를 보존하려고 추가하는 확장 헤더
        • 모든 프락시가 이런 식으로 동작하진 않음.
    사용자 로그인웹 사이트에 사용자 이름을 전달하는 자체적 체계 존재
    • WWW-Authenticate, Authorization 헤더
    • 사이트 접근 전 로그인 요구 → 401 Login Required 응답 코드 전송
      • 사용자가 요청마다 로그인하지 않게 브라우저 대부분은 사이트에 대한 로그인 정보를 기억하여 사이트로 보내는 각 요청에 로그인 정보를 전달하게 됨
    • 서버는 사이트 접근 전 로그인을 요구한다.
      • 401 상태코드와 WWW-authenticate 헤더를 전송한다.
    • 사용자가 이름과 비밀번호를 입력하고 브라우저는 기존 요청을 다시 보내서 사용자 식별을 시도한다.
    • 이제 서버는 사용자의 식별정보를 안다
    • 이후 요청에 대해, 브라우저는 서버로부터 사용자 식별 정보를 요청받으면, 서버에서 오는 요청에 대해 자동으로 사용자 이름과 비밀번호를 포함한다.
      • 요청하지 않았을 때에도 전달
    • 요청마다 해당 사용자의 식별정보 토큰을 Authorization 헤더에 담아 서버로 전송, 한 세션이 진행되는 내내 그 사용자에 대한 식별을 유지한다.
    단점 : 사이트를 옮겨다닐 때마다 각 사이트에 로그인 해야함.
    • 이름 선점, 비밀번호 규칙 차이 등
    뚱뚱한 URL
    • URL의 처음이나 끝에 어떤 상태정보를 추가해 확장
    • 사용자의 상태정보를 포함하고 있는 URL
    • 온라인 쇼핑몰을 돌아다니는 사용자에게 식별번호를 할당, 각 URL 뒤에 붙여서 사용자 추적
    HTTP 트랜잭션을 하나의 ‘세션’ or ‘방문’으로 묶는 용도
    1. 처음 방문한 사용자에 대한 유일한 ID 생성
    2. 서버가 인식 → 클라이언트를 fat url로 리다이렉트 시킴
    3. fat url을 포함한 요청을 받으면, 사용자 아이디와 관련된 추가적인 정보(쇼핑카트,프로필 등)를 찾아서 밖으로 향하는 모든 하이퍼링크를 fat url로 바꿈
    단점
    1. 못생긴 url - 사용자들에게 혼란을 줌
    2. 공유하지 못하는 url : 특정 사용자와 세션에 대한 상태정보 포함 → 개인정보를 공개하게됨
    3. 캐시를 사용할 수 없음 : URL이 달라지기 때문에 기존 캐시에 접근 불가능
    4. 서버 부하 가중 : fat url에 해당하는 html 페이지를 다시 그려야 함.
    5. 이탈 : 링크를 타고 다른 사이트로 이동하거나 특정 URL을 요청 → 의도치않게 해당 세션에서 ‘이탈’하게 됨
      1. 사전에 세션 정보가 추가된 링크만을 사용해야 fat url이 문제없이 동작함
      2. 이탈 시 초기화 후 처음부터 시작 ← 쇼핑 장바구니 등
    6. 세션 간 지속성의 부재 : 특정 Fat URL을 북마크하지 않는 이상, 로그아웃하면 모든 정보 유실
    쿠키
    • 넷스케이프 최초 개발
    • 캐시 충돌 가능성 → 쿠키에 있는 내용물 캐싱하지 않음
    타입
    • 세션 쿠키
      • 임시 쿠키
      • 사용자가 브라우저를 닫으면 삭제됨
    • 지속 쿠키
      • 디스크 저장 → 재시작 해도 남아있음.
    사이트마다 다른 쿠키
    • 쿠키를 모두 전달하면 성능 저하
    • 대부분의 쿠키는 서버에 특화된 이름/값 쌍 포함, 대부분 사이트에서는 인식하지 않는 무의미한 값
    광고 쿠키
    • 웹사이트와 협력업체의 광고계약
    • 광고들은 웹 사이트 자체의 일부인 것처럼 제작되고, 지속 쿠키를 만들어냄
    • 같은 광고사에서 제공하는 서로 다른 웹 사이트에 사용자가 방문하면, 브라우저는 앞서 만든 지속 쿠키를 다시 광고사 서버로 전송한다.
      • 지속 쿠키의 도메인이 같기 때문
    • Referer 헤더를 접목하여 사용자의 프로필과 웹 사이트를 사용하는 습관에 대한 방대한 데이터를 구축할 수 있음.
    • 최신 브라우저 개인정보 설정 기능 → 쿠키 사용 방식에 제약
    쿠키 Domain 속성 
    Set-cookie: user="mary17"; domain="example.com"
    • example.com으로 끝나는 사이트를 방문하면 Cookie: user=”mary17” 헤더가 항상 적용됨
    path 속성각각 쿠키를 별도로 갖는 두 개의 조직이 한 개의 웹 서버를 공유할 경우사용자가 /autos/ 경로에 접근하면 쿠키를 두 가지 받게됨.쿠키 구성요소
    • Version 1 쿠키 → Version 0 쿠키의 확장, 널리 쓰이진 않음
    • 최초의 쿠키 명세
    Set-Cookie: name=value [; expires=date] [; path=path] [; domain=domain] [; secure]
    • expires : 쿠키의 생명주기를 가리킴.
      • 요일, DD-MM-YY HH:MM:SS GMT
      • GMT만 사용가능
      • 쿠키에 Expires를 명시하지 않으면 사용자의 세션이 끝날 때 파기됨
    • domain
    • path
    • secure : HTTP가 SSL 보안 연결을 사용할 때만 쿠키 전송
      • client가 쿠키값을 변경할 수도 있음. → 쿠키 정보 변경 case
      • 클라이언트 개발할 때마다 기존 서버 쿠키를 받아서 행위등의 정보를 싣어서 서버에게 보낼 수 있음
      • secure 쿠키는 클라이언트에서 정보 변경 불가능
      • 개발할 땐 풀어놨다가, 운영 시에는 바꾸는 방식
    버전 1 쿠키(RFC2965) 는 폐기되어 더 이상 지원되지 않음
    • 쿠키마다 그 목적을 설명하는 설명문이 있음
    • 파기 주기에 상관없이 브라우저가 닫히면 쿠키를 강제로 삭제할 수 있다.
    • Max-Age: 절대 날짜 값 대신에 초 단위 상대값으로 생명 주기를 결정할 수 있음
    • URL의 포트번호로도 쿠키를 제어할 수 있음.
    • 도메인, 포트, 경로 필터가 있으면 Cookie 헤더에 담겨 되돌려보냄
    • cookie2 = “Cookie2:” cookie-version : 호환되는 버전 번호
    세션 추적개인정보 유출, 이전 사용자의 쿠키를 다른 사용자에게 할당 등 문제로 쿠키는 캐시하지 않는 게 좋음
    • 문서의 본문은 캐시하더라도 Set-Cookie 헤더는 제외해야함
      • 여러 사용자에게 보내게 되면, 사용자 추적에 실패함.
      • → 캐시는 공용인 경우가 많으니까 쿠키 헤더가 여러명에게 보내질 수 있다는건가?
    • 어떤 캐시는 응답을 저장하기 전에 Set-Cookie 헤더를 제거함 → 해당 헤더 정보가 없는 데이터를 받게 됨 → 문제 발생
      • 개선 방안 : 모든 요청마다 원 서버와 재검사해서 Set-Cookie 헤더 추가
    Cache-Control: **must-revalidate, max-age=0**
    • 보수적인 캐시는 콘텐츠가 캐시 가능한 데이터여도 set-cookie 헤더가 있는 응답은 캐시하지않을 수 있음
    • 어떤 캐시는 쿠키헤더가 있는 이미지는 캐시하고, 텍스트는 캐시하지 않기도 함.
    Cookie 헤더를 갖고 있는 요청을 주의해라
    • 요청 + 쿠키 = 결과 콘텐츠가 개인정보를 담고있을 수도 있다.
    • 위에서 말한 Set-Cookie 헤더가 포함된 이미지는 해도, 텍스트는 캐시하지 않는 경우에 속함.
    • 더 효율적인 방식 = 캐시 이미지에 파기 시간이 0인 cookie 헤더를 설정해서 매번 재검사하도록 강제함.
    <aside> 💡</aside>
    • 쿠키 사용 비활성화, 로그 파일 분석으로 대체도 가능
    • 원격 DB에 개인 정보를 저장하고, 쿠키에 해당 데이터의 키 값을 저장하는 방식을 사용하면, 클라이언트와 서버 사이에 예민한 데이터가 오가는 것을 줄일 수 있다.
    로그 파일을 분석해도 사용자의 브라우징 습관을 추적할 수 있다. 쿠키는 그것을 좀 더 편리하게 해주는 방식
    jwt 토큰도 쿠키에 저장해서 많이 사용함.
    • 불변으로 만들어놓기도 하고
    • 쿠키에 저장하는건 굉장히 위험 → 세션 스토리지
      • 세션 스토리지 - 요청을 하면 세션이 하나 만들어짐(커넥션처럼)
        • 서블릿 → jsession-id
        • 브라우저가 닫히기 전까지 정보가 디스크에 유지됨
        • 세션 id마다 할당된 스토리지
        • 중요 정보는 넣지 않는다.
        • mid(my id) - 클라이언트에 세팅 ← 이것과 뭔가 더 조합
          • 쿠키를 탈취하더라도 안전하도록
      • 로컬 스토리지 - 쿠키와 비슷한 애. 로컬 디스크에 저장, 아무나 볼 수 있음.
        • 브라우저 내 파일에 저장
    인증과 인가
    • 인증(Authentication)은 이 사람이 그 사람이 맞냐
    • 인가(Authorization)는 이 사람이 적법한 권한을 갖고 있는 유저인가.
      • 이 url에 보낼 수 있는가
    프록시 서버나 api gateway ip가 서버로 올라감
    • 진짜 클라이언트 ip는 X-Forward-For로 알아냄
    • 특정 ip나 대역만 서버를 사용할 수 있도록
      • ex) 가맹점 외 ip 대역은 통과 시키지 못하도록 사전 차단
      • 중간에 프록시가 껴있으면 검사가 안됨
    User-Agent
    • pc용 api, 모바일용 api 등 구분 가능
    Referer
    • 어떤 화면으로부터 api가 호출되었는지
    브라우저를 오픈할 때 세션이 만들어짐. → 세션 쿠키
    • user의 로그인한 키 세팅
    • 인증값, 보안적으로 필요, 일시적으로 저장해야하는 것들
    • 나 아닌 다른 유저가 세션 쿠키를 볼 수 없음.
    지속 쿠키에는 사용자의 로그인 키 세팅 안함
    • 처리상태, user의 상태 정보 등을 저장
    회원 탈퇴 정보는 서버. 클라이언트x쿠키를 http-response에 내려보는 테스트 해보기
    • secure 속성 설정
    샌드박스
    • 안팎으로 제한된
    회사에서 A.naver.com, B.naver.com 사용
    • CORS(Cross Origin Resource Sharing) : 어떤 도메인끼리는 CORS로 묶여있는 
저작자표시 비영리 변경금지