임시 페이지 입니다.

애드센스 승인을 위한 페이지이며, 내부 내용은 Tionlab와 아무런 관련이 없음을 알립니다.

이 페이지는 애드센스 승인이 되기전까지 해당 컨텐츠로 덮어쓰기됩니다. 양해바랍니다.

원본 레포지토리

no-referrer: Referer 헤더 생략 origin: Origin만 전송 origin-when-cross-origin: 동일한 프로토콜 보안 수준에서 same-origin 요청일 때는 Full URL을, cross-origin 요청 및 보안 수준이 낮을 때는 Origin만 전송 same-origin: same-origin일 때는 Full URL을, cross-origin일 때는 생략 strict-origin-when-cross-origin: same-origin일 때는 Full URL, cross-origin일 때는 프로토콜 보안 수준이 유지될 때에 한해 Origin만 전송, 보안 수준이 낮아진다면 No data unsafe-url: 무조건 Full URL (권장되지 않음) same-origin이라면, 프로토콜 보안 수준도 같을 것이므로 다운그레이드도 발생하지 않은 것입니다. Referer는 위에서 언급했던 것처럼 레퍼러 정책, Referrer-Policy가 어떻게 설정되느냐에 따라 결정됩니다. 만약 직접 명시하지 않으면 브라우저의 기본 정책을 따르게 되는데, 가급적이면 직접 명시하는 편이 바람직합니다. 그 이유는 아래와 같습니다. 브라우저에 따라 Referrer-Policy의 기본값이 다르거나, 구체적인 구현 내용이 다를 수도 있습니다. 또한 같은 브라우저에서도, 시크릿 모드(Incognito mode)와 같이 브라우징 모드에 따라서도 다르게 적용될 수 있는 등 일관적이지 않습니다. Referer trimming과 같이, 브라우저는 cross-origin 요청일 때 최대한 레퍼러를 엄격하게 제한하려고 하는 것이 기본적인 기조입니다. 때문에 브라우저에 의해 강제로 제어되기보다는, 개발자가 직접 예측 가능한 범위에서 의도적으로 제어하는 편이 테스트 등 통제의 측면에서 적절할 수 있습니다. 브라우저 별 기본 레퍼러 정책은 아래와 같습니다. 현재 시점에서는 strict-origin-when-cross-origin 정책이 보편적으로 적용된다고 할 수 있는데, 이는 대부분의 일반적인 상황에서 이 정책이 가장 합리적이고, 보안적으로도 바람직하기 때문입니다. Browser Referrer-Policy Chrome 85 버전부터 strict-origin-when-cross-origin (이전 버전의 경우 no-referrer-when-downgrade) Firefox strict-origin-when-cross-origin Edge no-referrer-when-downgrade → strict-origin-when-cross-origin Safari strict-origin-when-cross-origin 과 유사하게 동작 (자세한 내용은 webkit 블로그 참고) 일반적으로 레퍼러 정책은 아래와 같은 형태로 요청 헤더에 명시하지만, HTML이나 JavaScript로도 설정할 수 있습니다. Referrer-Policy: no-referrer Referrer-Policy: no-referrer-when-downgrade Referrer-Policy: origin Referrer-Policy: origin-when-cross-origin Referrer-Policy: same-origin Referrer-Policy: strict-origin Referrer-Policy: strict-origin-when-cross-origin Referrer-Policy: unsafe-url

문제의 원인과 해결 다시 서두에서 언급했던 이야기로 되돌아와 보자면, 결국 레퍼러가 유실되었던 문제는 페이지 간 스킴(HTTP/HTTPS)이 달랐기 때문이었습니다. 이런 부분에서 문제가 되었다는 점이 꽤나 민망할 수 있는 부분이지만, 당시 레퍼러 유실이 발생했던 페이지는 HTTPS로 마이그레이션이 되어 있지 않았던 상태였습니다. 이런 상황에서 두 페이지 간 사용자 행동 로그를 수집하는 경우가 있었던 것이고, 브라우저의 기본 정책인 strict-origin-when-cross-origin에 의해 레퍼러가 제거되었던 것입니다. 모든 페이지가 서로 동일한 보안 컨텍스트였다면 origin 정보를 확인할 수 있었겠지만, 일부 레거시 페이지가 잔존해 있었기 때문에 발생한 이슈였다고 할 수 있겠습니다. 사실, 레퍼러 같은 정보는 애초에 항상 존재하지 않을 수도 있다는 점을 전제하고 접근하는 편이 바람직합니다. 얼마든지 조작도 가능한 데다, 흔히 사용되는 광고 차단기(AdGuard 등)에 의해서도 제거될 수 있고, 심지어는 명시적으로 정책을 설정했더라도 그게 브라우저의 기본 정책보다 더 낮은 보안 수준이라면 브라우저가 이를 무시하고 기본 정책을 적용해버리기도 하기 때문입니다. 그래서 레퍼러에 의존하여 무언가를 하려는 것은 적절치 않을 수 있습니다. 만약 더 신뢰성 있거나 디테일한 정보가 필요하다면 다른 대안을 고려해야 합니다. 여하튼 이를 계기로 전반적으로 레퍼러 정책을 검토하여 필요한 경우 명시적으로 설정했고, 상황에 따라서는 레퍼러 대신 Origin 헤더를 확인한다거나 URL 쿼리 파라미터에 필요한 정보를 추가하는 식으로 대응하였습니다.