Preventing API Issues Caused by Edge Caching

no‑store와 no‑cache, 그 한 글자의 차이

웹·CDN 캐싱에서 가장 자주 헷갈리는 두 가지를 한 번에 정리한다: Cache-Control: no-store vs no-cache.

• no-store: 어떤 캐시(브라우저, 프록시, CDN)도 저장 자체를 하지 말라는 뜻입니다. 민감한 데이터나 아주 빠르게 바뀌는 API 응답에 적합합니다. (MDN Web Docs)

• no-cache: 저장은 해도 되지만 매번 원서버에 재검증해야 다시 쓰기 가능합니다. 즉 “캐시 금지”가 아니라 “재검증 필수”입니다. (MDN Web Docs)

CDN 동작(Cloudflare/CloudFront)도 함께 기억해요:

• Cloudflare는 기본 정책에서 no-store, no-cache, private, max-age=0 이 오면 캐시를 우회(BYPASS)합니다. 단, Cache Rules로 원본 지시를 무시하고 덮어쓸 수도 있습니다. (Cloudflare Docs)

• CloudFront는 최소 TTL이 0이면 원본의 캐시 지시(no-store, no-cache, max-age)를 존중합니다. stale-while-revalidate / stale-if-error도 지원합니다. (AWS Documentation)

언제 무엇을 써야 하나

• 로그인 세션, 결제정보, 개인화 응답, 민감 로그 등 절대 저장되면 안 되는 응답 → Cache-Control: no-store 권장. (Imperva)

• 변경이 잦지만 캐시 적중 이점도 약간 얻고 싶은 정적/반정적 응답 → Cache-Control: no-cache(+ ETag/Last-Modified)로 재검증 기반 캐싱. (MDN Web Docs)

• 정적 자산 성능 최적화 → public, max-age=..., stale-while-revalidate=..., stale-if-error=... 조합. (CloudFront/브라우저 모두 지원) (AWS Documentation)

바로 가져다 쓰는 헤더 스니펫

• 민감 API(절대 저장 금지):

Cache-Control: no-store

• 사용자별 개인화 페이지(브라우저만 저장 가능하게 막기):

Cache-Control: private, no-store

• 잦은 변경 + 재검증:

Cache-Control: no-cache (ETag 혹은 Last-Modified 함께)

• 정적 자산(성능 ↑, 최신성도 고려):

Cache-Control: public, max-age=3600, stale-while-revalidate=600, stale-if-error=86400 (AWS Documentation)

Cloudflare/CloudFront 팁

• Cloudflare에서 원본 지시를 그대로 따르게 하려면 Cache Rules에서 Respect origin을 선택하세요. 임의 TTL로 오버라이드하면 no-store도 무시될 수 있습니다. (Cloudflare Docs)

• CloudFront는 Minimum TTL=0 이어야 no-cache/재검증이 의도대로 동작합니다. (AWS Documentation)