본문 바로가기

CS 지식/브라우저

브라우저의 응답 캐싱 2 (+ Authorization 헤더란?)

반응형

브라우저의 응답 캐싱 2: Authorization 헤더란?

브라우저가 HTTP 응답을 캐싱하는 방식과, Authorization 헤더의 동작 원리를 함께 이해하면 인증 흐름에 대한 직관이 생긴다. 특히 Basic Authentication을 사용하는 경우, 브라우저의 동작을 정확히 이해하지 않으면 로그아웃이 불가능한 현상에 봉착하게 된다.

이 글에서는 다음과 같은 내용을 정리합니다.

  • Basic Auth가 URL에 포함될 때 어떤 방식으로 동작하는지
  • 브라우저가 인증 정보를 기억하는 방식
  • 캐시와 인증 캐시의 차이
  • 이를 무력화하거나 조작하는 방법
  • 의미 없는 쿼리스트링의 효과

1. Basic Auth와 URL

다음과 같은 URL을 살펴보자:

https://id:pw@xxx.domain.com/stats;json;norefresh

이 형식은 오래된 브라우저 기반의 Basic Authentication을 나타낸다. 여기서 id는 사용자명, pw는 비밀번호로, 브라우저는 이를 자동으로 인코딩해 Authorization 헤더에 다음과 같이 붙인다:

Authorization: Basic base64(id:pw)

즉, 클라이언트는 이 URL로 접속하는 순간 서버에 인증 요청을 하게 된다.


2. 인증 캐시의 원리

브라우저는 Authorization 정보를 세션 범위로 캐시한다. 한 번 인증에 성공하면, 같은 도메인과 인증 스코프에서는 이후 요청마다 자동으로 Authorization 헤더를 재사용하게 된다.

따라서, 처음 한 번 URL에 id:pw가 포함되면 이후부터는 xxx.domain.com에 대해 더 이상 URL에 인증 정보를 붙이지 않아도 된다. 브라우저가 Authorization 헤더를 자동으로 포함시키기 때문이다.

이 캐시는 브라우저를 완전히 종료하지 않는 이상 유지된다.


3. Basic Auth 로그아웃은 가능한가?

Basic Auth는 Stateless이기 때문에 서버 측 세션 로그아웃 개념이 없다. 따라서 인증을 해제하려면 클라이언트 쪽 캐시를 무효화하는 방식으로 접근해야 한다. 다음과 같은 방법이 있다:

방법 1. 강제 401 응답

서버에서 다음과 같이 강제로 인증 실패를 유도한다:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Basic realm="logout"

이렇게 하면 브라우저는 현재의 인증 정보가 유효하지 않다고 판단하고 Authorization 캐시를 제거한다.

방법 2. 잘못된 ID/PW로 덮어쓰기

의도적으로 틀린 자격정보를 담은 URL을 호출한다:

https://fake:wrong@xxx.domain.com/

브라우저는 기존 인증 정보를 덮어쓰며 캐시를 무력화한다. 다만, 브라우저마다 동작이 다를 수 있어 완전한 방법은 아니다.

방법 3. 브라우저 완전 종료

브라우저를 완전히 종료하면 인증 캐시가 사라진다. 단순히 탭을 닫는 것으로는 부족하다.


4. 쿼리스트링으로 캐시 회피

HTTP 응답은 URL을 기준으로 캐시되기 때문에, 의미 없는 쿼리스트링을 붙이면 콘텐츠 캐시를 회피할 수 있다.

예시:

fetch("/stats;json;norefresh?_=" + Date.now());

이런 요청은 매번 다른 URL로 간주되어 브라우저나 프록시 서버가 캐시를 사용하지 않고 항상 새 요청을 보내게 된다.

하지만 주의할 점은 다음과 같다:

Authorization 헤더의 캐시는 쿼리스트링으로 무효화되지 않는다.
브라우저는 인증 캐시와 리소스 캐시를 별도로 관리한다.


5. 정리

항목 설명 효과
URL에 id:pw 삽입 Basic Auth 방식 인증 Authorization 헤더 자동 생성
브라우저 캐시 Authorization 헤더를 세션 범위로 저장 이후 요청에도 자동 포함
강제 401 응답 인증 캐시 무효화 브라우저가 Authorization 제거
잘못된 id/pw 요청 기존 인증 정보 덮어쓰기 브라우저마다 다름
브라우저 재시작 세션 캐시 초기화 확실한 방식
쿼리스트링 추가 리소스 캐시 회피 인증 캐시에는 영향 없음

결론

Basic Auth는 간단하지만 인증 상태를 제어하기 어렵다. 특히 로그아웃 처리가 복잡하고 인증 캐시가 브라우저마다 다르게 동작한다는 점에서 보안적으로 취약하다. 이러한 특성을 이해하고, 상황에 따라 적절한 무력화 방법을 선택하는 것이 중요하다.

추천: 인증 관리가 중요한 시스템이라면 Basic Auth 대신 토큰 기반 인증 (예: JWT)을 사용할 것을 권장한다.

반응형