데이터 사이트를 공개할 때 가장 곤란한 순간은 "보안 설정을 강화했는데 기능이 깨지는" 경우입니다. 특히 지도, 임베드, 분석 스크립트처럼 외부 서비스를 불러오는 Datasette 사이트라면, 문제의 원인이 플러그인 코드가 아니라 HTTP 헤더 하나일 수 있습니다.
이번에 나온 datasette-referrer-policy 0.1은 그 작은 사례입니다. Datasette의 global-power-plants 데모에서 OpenStreetMap 타일이 제대로 표시되지 않았고, 원인 중 하나가 Referrer-Policy: no-referrer였습니다. OpenStreetMap은 리퍼러를 보내지 않는 사이트의 타일 요청을 차단할 수 있고, Datasette는 기본적으로 no-referrer를 사용하고 있었습니다.1
지도가 깨졌다면 먼저 네트워크 요청과 헤더를 보라
이번 사례에서 흥미로운 점은 "지도 오류"가 하나의 원인으로 설명되지 않았다는 것입니다. 확인된 문제는 두 가지였습니다. 하나는 CAPTCHA가 지도 플러그인의 .json 요청에도 걸려 HTML이 아닌 응답에서는 사용자가 풀 기회가 없었다는 점, 다른 하나는 OpenStreetMap 타일 요청이 리퍼러 정책 때문에 막혔다는 점입니다.1
실무적으로 이 조합은 흔합니다. 프론트엔드에서는 빈 지도, 깨진 타일, 멈춘 대시보드처럼 보이지만 실제 원인은 인증 미들웨어, 봇 방어, CORS, CSP, Referrer-Policy 같은 브라우저·서버 경계에 있을 수 있습니다.
해석하자면, Datasette처럼 "데이터를 바로 웹 앱으로 공개하는" 도구에서는 보안 기본값이 기능 기본값과 충돌할 가능성이 큽니다. 데이터 테이블만 제공한다면 no-referrer는 매우 보수적인 선택입니다. 하지만 지도 타일, 외부 차트, 분석 도구, 임베드 위젯을 붙이는 순간 외부 서비스는 "어느 사이트에서 온 요청인가"를 운영 정책의 일부로 볼 수 있습니다.
no-referrer가 항상 정답은 아니다
Referrer-Policy는 브라우저가 다른 출처로 요청을 보낼 때 현재 페이지 정보를 얼마나 함께 보낼지 정하는 헤더입니다. no-referrer는 아무 정보도 보내지 않는 가장 강한 선택이고, strict-origin-when-cross-origin은 같은 출처에는 전체 URL을 보내되, 다른 출처에는 origin만 보내며 HTTPS에서 HTTP로 내려갈 때는 보내지 않는 방식으로 설명됩니다.2
여기서 중요한 구분은 "보안 헤더를 켰는가"가 아니라 "어떤 데이터 노출을 줄이고, 어떤 기능을 유지할 것인가"입니다.
Datasette 사이트가 비공개 데이터, 토큰이 포함된 URL, 민감한 쿼리 파라미터를 다룬다면 no-referrer는 설득력 있는 선택입니다. 반대로 공공 데이터 포털처럼 공개 URL이 주가 되고 OpenStreetMap, Matomo, 외부 대시보드, 문서 임베드를 함께 쓴다면 strict-origin-when-cross-origin이 더 균형 잡힌 기본값일 수 있습니다.
datasette-referrer-policy 플러그인은 설치하면 Datasette 인스턴스의 모든 페이지에 Referrer-Policy: strict-origin-when-cross-origin을 반환하도록 되어 있고, 설정을 통해 다른 정책으로 바꿀 수 있습니다.3 즉 "Datasette의 기본값을 모두 바꾸는" 변화가 아니라, 필요한 배포에서 명시적으로 헤더를 조정하는 도구에 가깝습니다.
Datasette 배포 전 체크리스트
이 플러그인을 무조건 설치할 필요는 없습니다. 다만 외부 리소스를 불러오는 Datasette 사이트라면 출시 전 다음 순서로 확인하는 편이 좋습니다.
지도 타일, 분석 스크립트, iframe, CDN 자산, 외부 API 호출을 목록화한다.
브라우저 개발자 도구의 Network 탭에서 실패한 요청의 상태 코드와 요청 헤더를 확인한다.
응답 헤더에 실제로 어떤
Referrer-Policy가 붙는지 본다.no-referrer,same-origin,strict-origin,strict-origin-when-cross-origin중 사이트 성격에 맞는 정책을 고른다.Datasette 플러그인 설치 여부와 설정이 배포 환경에 포함됐는지 확인한다.
Datasette 플러그인은 같은 환경에 설치해 기능을 확장하는 방식이며, 공식 문서에서도 datasette install 명령으로 플러그인을 설치하는 흐름을 안내합니다.4 따라서 이 문제를 Nginx나 Cloud Run 설정에서 해결할 수도 있지만, Datasette 배포 단위 안에서 관리하고 싶다면 플러그인이 더 명확한 선택입니다.
결론은 간단합니다. 공개 Datasette 사이트에 지도나 외부 임베드가 있다면 Referrer-Policy를 보안 체크리스트가 아니라 기능 호환성 체크리스트에도 넣어야 합니다. datasette-referrer-policy 0.1은 작은 플러그인이지만, 데이터 퍼블리싱에서 "프라이버시 기본값"과 "웹 생태계와의 협업"이 늘 함께 설계돼야 한다는 점을 잘 보여줍니다.
참고
1datasette-referrer-policy 0.1
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.