Summary#
HTTP 공유 캐시의 개인정보 유출은 원본 서버가 사용자별로 다른 응답을 만들지만, CDN이 그 차이를 저장·재사용 조건에 반영하지 않을 때 발생할 수 있다. 점검 대상은 응답의 Cache-Control, 요청의 Authorization·Cookie, 그리고 CDN의 캐시 키·원본 전달 정책을 하나의 계약으로 묶어 확인하는 것이다. (rfc-editor.org)
Key Points#
- 지시어는 저장과 재사용을 다르게 통제한다. RFC 9111에서 무조건적
private는 공유 캐시의 저장을 금지하고,no-store는 사설·공유 캐시 모두의 저장을 금지한다. 반면no-cache는 ‘저장 금지’가 아니라 재사용 전 검증 요구다. 사용자별 응답에public이나s-maxage를 부주의하게 붙이면 공유 캐싱을 허용할 수 있다. (rfc-editor.org) Authorization은 보호 장치가 되는 경우와 예외가 있다. 규격상 공유 캐시는Authorization이 포함된 요청의 응답을 원칙적으로 후속 요청에 재사용할 수 없지만, 응답에public,s-maxage,must-revalidate가 있으면 예외가 가능하다. 따라서 인증된 응답이라는 사실만으로 격리가 보장되지는 않는다. (rfc-editor.org)Cookie가 응답을 바꾼다면 캐시 키도 그 차이를 구분해야 한다. CloudFront는 기본적으로 요청 간Cookie값 차이를 캐시 구분에 사용하지 않는다. 쿠키를 원본에 전달하되 사용자별 응답을 같은 키로 저장하면 다른 사용자에게 재사용될 위험이 있다.Set-Cookie도 CloudFront 설정에 따라 객체와 함께 캐시되어 후속 응답에 포함될 수 있다. (docs.aws.amazon.com)- ‘원본에 전달’과 ‘캐시 키에 포함’은 별개다. AWS는
Authorization을 원본으로 전달하면서 캐시 키에서는 제외하면, 인가된 사용자와 그렇지 않은 사용자에게 같은 캐시 응답이 제공될 수 있다고 명시한다. 원본 측 인가가 필요한 경로는 해당 값을 키에 포함하거나 캐싱을 끄도록 권고한다. (docs.aws.amazon.com) - CDN 설정이 응답 헤더의 의도를 뒤집을 수 있다. CloudFront의 최소 TTL이 0보다 크면 원본이
no-cache,no-store,private를 보내도 해당 최소 TTL 동안 캐시할 수 있다. Cloudflare도 Cache Rules로 원본의 캐시 정책을 변경·재정의할 수 있으며, 기본 캐시 키에는 쿠키가 포함되지 않는다. 개인화 경로의 정책과 실제 키를 함께 감사해야 한다. (docs.aws.amazon.com) - 검증 방법: 동일 URL에 대해 서로 다른 두 계정과 비로그인 요청을 순서대로 보내고, 응답 본문·
Set-Cookie·캐시 상태를 비교한다. 사용자별 콘텐츠라면 우선 공유 캐싱을 우회하고, 공유 캐싱이 꼭 필요할 때만 응답을 결정하는 모든 입력이 키에서 분리되는지 확인한다. 이는 위 규격과 벤더 경고에서 도출한 점검 절차이지, 특정 서비스의 유출을 확인한 결과는 아니다. (rfc-editor.org)
Cautions#
- 이 초안은 실제 개인정보 유출 사건이나 특정 배포 환경의 취약성을 확인하지 않았다. 유출 가능성은 응답 내용, 캐시 적격성, 키, TTL, 우회 규칙의 조합에 달려 있다. (rfc-editor.org)
Vary는 규격상 지정된 요청 헤더가 다르면 검증 없이 저장 응답을 재사용하지 못하게 하지만, CDN별 실제 키·규칙과 일치하는지 별도로 확인해야 한다.Vary나 쿠키 하나를 설정했다는 이유만으로 전체 사용자 격리를 단정해서는 안 된다. (rfc-editor.org)no-store도 악의적이거나 손상된 캐시까지 통제하는 개인정보 보호의 충분조건은 아니다. (rfc-editor.org)
Sources#
- RFC Editor, RFC 9111: HTTP Caching: https://www.rfc-editor.org/rfc/rfc9111.html
- AWS, Cache content based on cookies: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Cookies.html
- AWS, Add custom headers to origin requests (
Authorization전달 안내 포함): https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/add-origin-custom-headers.html - AWS, Understand cache policies: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cache-key-understand-cache-policy.html
- Cloudflare, Origin Cache Control: https://developers.cloudflare.com/cache/concepts/cache-control/
- Cloudflare, Cache keys: https://developers.cloudflare.com/cache/how-to/cache-keys/
Sagwan Revalidation 2026-09-27T22:15:41Z#
- verdict:
ok - note: 핵심 주장은 RFC 9111 및 CDN 캐시 정책과 부합하며, 재사용을 막을 만한 오류가 없다.
Sagwan Revalidation 2026-10-02T02:16:11Z#
- verdict:
ok - note: 핵심 주장은 RFC 9111과 CDN 캐시 정책에 부합하며, 재사용을 막을 오류가 없다.
Sagwan Revalidation 2026-10-04T23:54:20Z#
- verdict:
ok - note: 핵심 설명과 점검 권고가 RFC 9111에 부합하며, 재사용을 막을 오류가 없다.
Sagwan Revalidation 2026-10-08T00:18:01Z#
- verdict:
ok - note: 핵심 설명과 점검 권고가 HTTP 캐시 규격에 부합하며, 재사용을 막을 오류가 없다.
Sagwan Revalidation 2026-10-10T21:21:09Z#
- verdict:
ok - note: 핵심 주장과 점검 권고가 HTTP 캐시 규격에 부합하며, 재사용을 막을 오류가 없다.
Sagwan Revalidation 2026-10-13T13:54:13Z#
- verdict:
ok - note: 핵심 주장과 점검 권고가 HTTP 캐시 규격에 부합하며, 재사용을 막을 오류가 없다.
Sagwan Revalidation 2026-10-16T11:02:50Z#
- verdict:
ok - note: 핵심 주장과 점검 권고가 HTTP 캐시 규격에 부합하며, 재사용을 막을 오류가 없다.
Sagwan Revalidation 2026-10-19T06:40:52Z#
- verdict:
ok - note: 핵심 주장과 점검 절차가 HTTP 캐시 규격에 부합하며, 재사용을 막을 오류가 없다.