1. 웹 캐시란 무엇인가#

웹 캐시는 서버 응답을 임시로 저장해두었다가 같은 요청이 다시 들어왔을 때 저장된 응답을 재사용하는 기술이다.

예를 들어 사용자가 다음 파일을 요청한다고 하자.

1
GET /static/main.css HTTP/1.1
2
Host: example.com

서버가 매번 CSS 파일을 새로 보내는 대신, 브라우저는 이전에 받은 응답을 저장해두고 다시 사용할 수 있다.

1
HTTP/1.1 200 OK
2
Content-Type: text/css
3
Cache-Control: public, max-age=31536000

위 응답은 “이 리소스는 공개 캐시에 저장해도 되고, 31536000초 동안 재사용할 수 있다”는 의미이다.

캐시가 사용되는 위치는 여러 곳이다.

보통 이미지, 폰트, CSS, JS 같은 정적 파일은 캐시하기 적합하다. 반대로 마이페이지, 결제 내역, 개인 설정, 관리자 페이지처럼 사용자마다 달라지는 응답은 캐싱에 주의해야 한다.

2. Cache-Control 헤더#

HTTP 캐시 정책에서 가장 중요한 헤더는 Cache-Control이다. 서버는 이 헤더를 통해 브라우저나 CDN에게 응답을 어떻게 저장해야 하는지 알려준다.

대표적인 값은 다음과 같다.

예를 들어 정적 파일은 다음과 같이 설정할 수 있다.

1
Cache-Control: public, max-age=31536000, immutable

반대로 개인정보가 담긴 응답은 다음과 같이 설정하는 것이 안전하다.

1
Cache-Control: no-store

1
Cache-Control: public, max-age=86400

1
HTTP/1.1 200 OK
2
Cache-Control: public, max-age=600
3

4
{
5
  "username": "panda",
6
  "email": "panda@example.com"
7
}

1
Cache-Control: private, max-age=300

1
Cache-Control: no-store

1
Cache-Control: no-cache

3. 캐시 키란 무엇인가#

캐시는 요청을 구분하기 위해 기준값을 사용한다. 이를 캐시 키라고 한다.

가장 단순하게는 URL이 캐시 키가 된다.

1
https://example.com/static/main.css

사용자가 같은 URL을 다시 요청하면 캐시는 저장된 응답을 반환할 수 있다.

하지만 실제 웹에서는 URL만으로 응답을 구분하기 어려운 경우가 많다. 같은 URL이라도 요청 헤더, 쿠키, 언어 설정, 인코딩 방식에 따라 응답이 달라질 수 있기 때문이다.

예를 들어 다음 두 요청은 같은 URL을 요청하지만 사용자 쿠키가 다르다.

1
GET /mypage HTTP/1.1
2
Host: example.com
3
Cookie: session_id=user_a

1
GET /mypage HTTP/1.1
2
Host: example.com
3
Cookie: session_id=user_b

만약 캐시가 쿠키를 고려하지 않고 URL만 기준으로 응답을 저장한다면 문제가 생긴다. user_a의 마이페이지 응답이 캐시에 저장된 뒤, user_b에게 그대로 전달될 수 있기 때문이다.

이것이 캐시 정보 유출의 핵심 원리이다.

4. 개인 응답 캐싱으로 인한 정보 유출#

가장 직관적인 캐시 취약점은 개인 응답이 공유 캐시에 저장되는 경우이다.

예를 들어 로그인한 사용자가 /api/me를 요청한다고 하자.

1
GET /api/me HTTP/1.1
2
Host: example.com
3
Cookie: session_id=abc123

서버가 다음과 같이 응답했다.

1
HTTP/1.1 200 OK
2
Content-Type: application/json
3
Cache-Control: public, max-age=600
4

5
{
6
  "id": 1,
7
  "name": "panda",
8
  "email": "panda@example.com"
9
}

여기서 문제는 Cache-Control: public이다. 이 응답은 특정 사용자의 개인정보를 포함하지만, 공유 캐시에 저장 가능하다고 표시되어 있다.

이후 다른 사용자가 같은 API를 요청하면 캐시는 원래 서버까지 가지 않고 저장된 응답을 반환할 수 있다.

1
GET /api/me HTTP/1.1
2
Host: example.com
3
Cookie: session_id=other_user

캐시가 잘못 동작하면 다른 사용자에게 panda@example.com이 포함된 응답이 전달될 수 있다.

이런 문제는 단순한 성능 버그가 아니라 개인정보 유출 취약점이다.

5. CDN 캐시와 보안#

CDN은 사용자의 위치와 가까운 엣지 서버에서 정적 파일을 제공해 성능을 높이는 서비스이다. 대표적으로 이미지, JS, CSS, 다운로드 파일 등을 빠르게 제공하기 위해 사용된다.

CDN의 기본 구조는 다음과 같다.

정적 파일에는 매우 유용하지만, 동적 응답에 CDN 캐시가 적용되면 위험해진다.

예를 들어 다음과 같은 URL이 있다고 하자.

1
https://example.com/dashboard

이 페이지는 로그인한 사용자마다 다른 내용을 보여준다. 그런데 CDN이 URL만 보고 이 페이지를 캐싱하면 첫 번째 사용자의 대시보드가 다른 사용자에게 노출될 수 있다.

따라서 CDN을 사용할 때는 어떤 경로를 캐시할지 명확하게 구분해야 한다.

캐시 대상 경로를 넓게 잡으면 보안 사고로 이어질 수 있다.

6. Vary 헤더#

Vary 헤더는 캐시가 어떤 요청 헤더를 기준으로 응답을 구분해야 하는지 알려준다.

예를 들어 서버가 언어 설정에 따라 다른 응답을 반환한다고 하자.

1
GET /notice HTTP/1.1
2
Host: example.com
3
Accept-Language: ko

1
GET /notice HTTP/1.1
2
Host: example.com
3
Accept-Language: en

이 경우 같은 /notice URL이라도 언어에 따라 응답이 달라질 수 있다. 서버는 다음과 같이 응답할 수 있다.

1
Vary: Accept-Language

이 헤더는 캐시에게 Accept-Language 값이 다르면 서로 다른 응답으로 취급하라고 알려준다.

인증과 관련된 응답에서는 쿠키나 Authorization 헤더에 따라 응답이 달라질 수 있다. 그런데 이런 응답은 대체로 공유 캐시에 저장하지 않는 것이 더 안전하다.

1
Cache-Control: no-store

즉, Vary는 캐시 구분 기준을 알려주는 장치이지만, 민감한 응답을 안전하게 만드는 만능 해결책은 아니다.

7. 캐시 키 불일치 문제#

캐시 보안에서 중요한 문제 중 하나는 서버가 응답을 만들 때 참고한 값과 캐시가 구분 기준으로 삼는 값이 다를 때 발생한다.

예를 들어 서버가 X-Forwarded-Host 헤더를 사용해 페이지 안의 링크를 만든다고 하자.

1
GET /reset HTTP/1.1
2
Host: example.com
3
X-Forwarded-Host: attacker.example

서버가 이 헤더를 신뢰해서 응답 내부에 다음과 같은 링크를 넣는다면 문제가 생길 수 있다.

1
<a href="https://attacker.example/reset/confirm">비밀번호 재설정</a>

그런데 캐시는 X-Forwarded-Host를 캐시 키에 포함하지 않고 URL만 기준으로 응답을 저장한다고 하자.

1
캐시 키: https://example.com/reset

이 경우 조작된 응답이 캐시에 저장되고, 이후 정상 사용자가 /reset에 접속했을 때 오염된 응답을 받을 수 있다.

이처럼 서버는 어떤 헤더를 보고 응답을 바꾸는데, 캐시는 그 헤더를 구분하지 않는 상황을 캐시 키 불일치 문제라고 볼 수 있다.

8. Web Cache Poisoning이란 무엇인가#

Web Cache Poisoning은 공격자가 캐시에 저장될 응답을 조작하여, 이후 다른 사용자에게 오염된 응답이 전달되게 만드는 공격이다.

핵심 흐름은 다음과 같다.

1. 공격자가 특정 요청을 조작한다.
2. 서버가 조작된 요청을 바탕으로 응답을 생성한다.
3. CDN이나 프록시 캐시가 그 응답을 저장한다.
4. 다른 사용자가 같은 캐시 키로 요청한다.
5. 캐시가 오염된 응답을 반환한다.

여기서 중요한 점은 공격자가 서버를 직접 해킹하지 않아도 된다는 것이다. 서버가 특정 헤더나 파라미터를 응답에 반영하고, 캐시가 이를 잘못 저장하면 문제가 발생할 수 있다.

예를 들어 다음과 같은 응답이 있다고 하자.

1
HTTP/1.1 200 OK
2
Cache-Control: public, max-age=600
3
Content-Type: text/html

1
<script src="https://cdn.example.com/app.js"></script>

만약 서버가 특정 헤더를 기반으로 스크립트 주소를 바꾸고, 그 응답이 공유 캐시에 저장된다면 다른 사용자에게도 조작된 스크립트 주소가 포함된 페이지가 전달될 수 있다.

Web Cache Poisoning은 일반적인 XSS와 다르게 “한 번의 응답 조작”이 캐시를 통해 여러 사용자에게 영향을 줄 수 있다는 점에서 위험하다.

9. 캐시와 XSS가 연결되는 경우#

캐시 자체가 JavaScript를 실행하는 것은 아니다. 하지만 캐시된 응답 안에 공격자가 조작한 HTML이나 JavaScript 경로가 포함되면 XSS와 연결될 수 있다.

예를 들어 서버가 어떤 요청 값을 검증 없이 HTML에 반영한다고 하자.

1
<script src="https://example.com/static/app.js"></script>

그런데 특정 헤더나 파라미터에 의해 이 값이 바뀔 수 있다면 다음과 같은 문제가 생길 수 있다.

1
<script src="https://attacker.example/app.js"></script>

이 응답이 캐시에 저장되면 이후 정상 사용자도 오염된 응답을 받을 수 있다.

즉, Web Cache Poisoning은 다음 문제들이 함께 겹칠 때 발생하기 쉽다.

• 서버가 특정 요청 값을 응답에 반영함
• 해당 값이 캐시 키에 포함되지 않음
• 응답이 공유 캐시에 저장됨
• 응답이 HTML, JavaScript, 리다이렉트 등 보안에 민감한 동작에 영향을 줌

따라서 캐시 보안은 단순히 Cache-Control만 보는 것이 아니라, 서버가 어떤 요청 값을 신뢰하는지도 함께 봐야 한다.

10. 안전한 캐시 설계 방법#

1
Cache-Control: no-store

1
Cache-Control: no-store
2
Pragma: no-cache
3
Expires: 0

1
/static/*
2
/assets/*
3
/images/*

1
/api/*
2
/mypage
3
/dashboard
4
/admin/*
5
/auth/*
6
/payment/*

1
/*

1
/static/*
2
/assets/*
3
/images/*

1
좋은 방식: 설정 파일의 BASE_URL 사용
2
위험한 방식: 요청 헤더의 Host 값을 그대로 사용

1
Cache-Control: private

1
Cache-Control: no-store

11. 개발자가 확인해야 할 체크리스트#

웹 캐시를 사용할 때는 다음 항목을 확인하는 것이 좋다.

• 개인정보가 담긴 응답에 Cache-Control: no-store가 설정되어 있는가?
• 로그인, 로그아웃, 회원정보, 결제, 관리자 페이지가 CDN에 캐시되지 않는가?
• CDN이 전체 경로를 캐시하도록 설정되어 있지 않은가?
• 정적 파일과 동적 페이지의 경로가 명확하게 분리되어 있는가?
• 사용자마다 달라지는 API 응답이 공유 캐시에 저장되지 않는가?
• public 캐시 정책이 민감한 응답에 적용되지 않았는가?
• 서버가 Host, X-Forwarded-Host 같은 요청 헤더를 응답 생성에 그대로 사용하지 않는가?
• 캐시 키에 포함되지 않는 값이 응답에 영향을 주지 않는가?
• Vary 헤더가 필요한 응답에 적절히 설정되어 있는가?
• 캐시 설정 변경 후 실제 응답 헤더를 확인했는가?

캐시는 설정 파일에서만 확인하면 안 된다. 실제 배포 환경에서 브라우저 개발자 도구나 프록시 도구를 통해 응답 헤더를 직접 확인해야 한다.

12. 마무리#

오늘은 웹 캐시가 어떻게 정보 유출 취약점으로 이어질 수 있는지 알아보았다. 캐시는 성능 최적화를 위한 기술이지만, 잘못 설정하면 개인 응답이 다른 사용자에게 노출되거나 오염된 응답이 CDN을 통해 전파될 수 있다.

핵심은 간단하다. 공개 정적 파일은 적극적으로 캐시하되, 사용자별로 달라지는 응답은 공유 캐시에 저장하지 않아야 한다. 특히 로그인 상태, 개인정보, 결제, 관리자 페이지와 관련된 응답에는 Cache-Control: no-store를 적용하는 것이 안전하다.

또한 캐시 키와 응답 생성 기준이 어긋나면 Web Cache Poisoning 같은 문제가 발생할 수 있다. 서버가 어떤 요청 값을 신뢰하는지, CDN이 어떤 기준으로 응답을 저장하는지 함께 확인해야 한다.

웹 캐시는 단순히 빠른 사이트를 만들기 위한 기능이 아니다. 잘못된 응답을 저장하지 않고, 잘못된 사용자에게 전달하지 않도록 설계해야 하는 보안 요소이다. 성능 최적화와 보안은 따로 떨어진 개념이 아니라, 같은 구조 위에서 함께 설계되어야 한다.