Hacker News 2026.03.31 26

Railway에서 벌어진 CDN 캐싱 사고 — 남의 응답이 내 화면에 뜬다고요?

무슨 일이 있었나요?

2026년 3월 30일, 클라우드 배포 플랫폼 Railway에서 꽤 심각한 보안 사고가 발생했어요. 어떤 사용자가 자기 대시보드에 접속했는데, 다른 사용자의 데이터가 보이는 현상이 일어난 거예요. 이게 뭐냐면, CDN(Content Delivery Network) 캐싱이 의도치 않게 활성화되면서, 특정 사용자에게 보여줘야 할 응답이 캐시에 저장됐고, 그 캐시된 응답이 다른 사용자에게 그대로 전달된 거예요.

CDN이 뭔지 간단히 설명하면, 전 세계 여러 곳에 서버를 두고 콘텐츠를 미리 복사해둬서 사용자에게 빠르게 전달하는 시스템이에요. 이미지, CSS, JavaScript 파일 같은 모든 사용자에게 동일한 콘텐츠를 캐싱하면 아주 좋은데, 문제는 사용자마다 다른 콘텐츠(예: 대시보드, 계정 정보)까지 캐싱해버리면 A 사용자의 데이터가 B 사용자에게 보이는 심각한 상황이 발생한다는 거죠.

기술적으로 어떻게 이런 일이 생기나요?

CDN 캐싱 사고는 보통 Cache-Control 헤더 설정이 잘못됐을 때 발생해요. HTTP 응답에는 Cache-Control이라는 헤더가 있는데, 이게 "이 응답을 캐시해도 돼" 또는 "절대 캐시하지 마"라고 CDN에게 지시하는 역할을 해요.

예를 들어 Cache-Control: public, max-age=3600이라고 설정하면, CDN이 이 응답을 1시간 동안 저장해두고 같은 URL로 요청이 오면 원본 서버까지 가지 않고 바로 캐시된 응답을 돌려줘요. 이게 정적 파일에는 완벽하지만, 로그인한 사용자의 개인 데이터가 담긴 API 응답에 이런 설정이 들어가면 재앙이 되는 거예요.

Railway의 경우, 인프라 변경 과정에서 CDN 설정이 의도치 않게 바뀌면서 캐싱되면 안 되는 응답까지 캐싱된 것으로 보여요. 이런 종류의 실수는 생각보다 자주 발생하는데요, CDN 설정이 복잡하고 계층적이다 보니 하나의 변경이 예상치 못한 범위까지 영향을 미칠 수 있거든요.

올바른 설정은 개인화된 응답에 Cache-Control: private, no-store를 붙이는 거예요. private는 CDN 같은 공유 캐시에 저장하지 말라는 뜻이고, no-store는 어디에도 캐시하지 말라는 뜻이에요. 또는 Vary: Cookie 헤더를 사용해서 쿠키가 다른 요청은 별도의 캐시 엔트리로 처리하게 할 수도 있지만, 이것만으로는 충분하지 않은 경우가 많아요.

이전에도 비슷한 사고가 있었어요

이런 CDN 캐싱 사고는 테크 업계에서 반복적으로 발생해왔어요. 가장 유명한 사례 중 하나가 2017년 Cloudflare의 Cloudbleed 사건인데요, CDN 프록시의 버그로 인해 다른 사이트의 메모리 데이터가 응답에 섞여 나가는 일이 있었어요. 규모는 다르지만 "CDN 레이어에서 데이터가 섞인다"는 본질은 같아요.

GitHub도 2020년에 비슷한 사고를 겪었고, Fastly CDN에서도 설정 오류로 캐싱 문제가 발생한 적이 있어요. 핵심은, CDN은 성능을 위해 반드시 필요하지만 잘못 설정하면 보안 사고로 직결된다는 거예요. 특히 인증이 필요한 페이지, API 응답, 사용자별 데이터를 다루는 엔드포인트에서는 캐싱 정책을 아주 신중하게 설정해야 해요.

한국 개발자에게 주는 시사점

이 사고에서 배울 점은 분명해요. 여러분이 서비스를 운영하고 있다면, 지금 당장 확인해볼 것들이 있어요.

첫째, 인증이 필요한 API 응답에 Cache-Control 헤더가 제대로 설정되어 있는지 확인하세요. 프레임워크 기본값에 의존하지 말고 명시적으로 no-store를 지정하는 게 안전해요. Next.js나 Nuxt 같은 SSR 프레임워크를 쓴다면, 페이지별로 캐싱 정책이 다를 수 있으니 특히 주의가 필요해요.

둘째, CDN 설정을 변경할 때는 개인화된 응답이 캐싱되지 않는지 반드시 테스트하세요. 서로 다른 계정으로 로그인해서 같은 URL을 요청했을 때 응답이 올바른지, 응답 헤더에 X-Cache: HIT 같은 캐시 적중 표시가 있는 건 아닌지 확인해보는 거예요.

셋째, Railway처럼 PaaS(Platform as a Service)를 사용할 때도 CDN 설정이 어떻게 되어 있는지 이해하고 있어야 해요. 플랫폼이 알아서 해줄 거라고 맡기기만 하면, 이런 사고가 났을 때 영향 범위조차 파악하기 어려워요.