보안 연결을 점검할 이유와 판단 범위
병원 홈페이지의 HTTPS를 점검할 이유는 공개 안내가 사용자에게 안전한 연결로 제공되는지 알아보기 위해서입니다. Google의 페이지 경험 안내는 페이지가 안전하게 제공되는지를 자체 평가 질문으로 제시하고 보안 HTTPS 페이지의 제공 상태를 참고하도록 설명합니다. 다만 HTTPS를 적용했다는 사실을 높은 검색 순위의 약속이나 사이트 전체 보안의 완료 표시로 사용해서는 안 됩니다.
이 판단은 사용자가 자료를 전달받는 연결과 관련됩니다. 페이지 주소에 HTTPS가 있다는 정보만으로 서버의 모든 접근 권한이나 개인정보 관리 상태가 입증되는 것은 아닙니다. 확인하려는 대상이 연결의 상태인지 다른 보안 기능인지를 구별해야 합니다. 병원이라는 업종 이름이나 인증서 설치 완료라는 설명으로 서로 다른 보안 대상 전체를 평가할 수는 없습니다.
Google은 사이트 연결이 안전한지 Chrome에서 알아보는 방법을 페이지 경험 리소스로 안내합니다. 또 HTTPS 보고서는 보안 페이지를 제공하는지와 제공하지 않는 경우 무엇을 수정할지 이해하는 자료로 소개됩니다. 이 자료의 목적은 HTTPS 상태의 점검입니다. 개별 병원의 정보 보호 전반을 심사한 결과나 의료 정보의 정확성을 판정하는 도구로 확대하여 읽지 않습니다.
설치한 기능의 이름과 현재 제공되는 연결은 별도로 이해할 대상입니다. 홈페이지에 인증서를 적용했다는 작업 보고가 있어도 어떤 주소와 리소스가 실제로 어떻게 열리는지라는 질문이 남습니다. 특히 문서가 가져오는 파일의 연결이 주 문서와 같지 않을 수 있습니다. 연결을 판단할 때 문서의 시작 주소만 읽는 방식으로는 이러한 관계가 드러나지 않을 수 있습니다.
검토 자료도 같은 범위를 답하는지 구별해야 합니다. 보고서가 설명하는 HTTPS 페이지의 상태와 사용자가 특정 주소에서 받은 연결 정보는 관측 대상이 다릅니다. 특정 오류가 발생한 이유를 알려면 실제 응답과 브라우저의 정보를 읽어야 합니다. 일반 안내의 가능성만으로 인증서 설정이나 서버 구성의 어느 항목이 잘못되었다고 판정하지 않습니다.
| 활성 혼합 콘텐츠의 영향 | 공식 자료의 공격 예 | 연결 보안과 관련된 대상 |
|---|---|---|
| 로그인 정보 | 비밀번호나 인증 정보 도용 | 사용자를 식별하는 데이터 |
| 세션 정보 | 사용자 세션 쿠키 도용 | 로그인 상태와 관련된 정보 |
| 이동 대상 | 다른 사이트로 리디렉션 | 사용자가 도착하는 주소 |
| 내용 표시 | 다른 콘텐츠의 표시 | 문서에서 실제 전달하는 설명 |
HTTPS 문서 안의 HTTP 리소스
혼합 콘텐츠는 초기 HTML을 HTTPS 연결로 가져왔지만 다른 리소스를 보안되지 않은 HTTP 연결로 불러오는 경우입니다. 이미지와 동영상, 스타일시트와 스크립트가 그러한 리소스의 예입니다. 따라서 페이지의 시작 주소가 HTTPS라는 사실과 페이지 안의 모든 요청이 같은 연결을 사용한다는 사실은 다릅니다. 홈페이지에서 어떤 파일을 참조하는지의 관계가 보안 판단에 들어갑니다.
web.dev의 설명은 보안되지 않은 하위 리소스 요청이 네트워크 경로의 공격에 취약해 페이지의 보안을 약화한다고 안내합니다. 공격자가 통신을 보거나 수정할 수 있는 조건이라는 뜻입니다. 병원 페이지에 이러한 요청이 실제로 있는지와 공격이 발생했는지는 다른 질문입니다. 가능성의 설명을 개별 병원의 사고가 확인되었다는 주장으로 바꾸지 않습니다.
공식 자료는 혼합 콘텐츠를 수동과 활성 두 유형으로 설명합니다. 수동 유형에는 이미지와 동영상, 오디오가 포함되며 페이지의 나머지 부분과 상호작용하지 않아 공격자가 변경할 수 있는 작업이 제한됩니다. 제한된다는 말은 안전 문제가 없다는 뜻은 아닙니다. 사용자가 받아 보는 매체가 통신 중에 가로채이거나 대체되는 문제는 여전히 가능합니다.
예를 들어 자료에는 버튼 이미지를 대체해 사용자가 저장과 삭제를 혼동하게 만들 수 있다는 설명이 있습니다. 화면의 그림도 기능을 이해하는 정보가 될 수 있기 때문입니다. 사진이나 아이콘의 요청을 본문과 관계없는 장식으로만 읽으면 이런 영향을 놓칠 수 있습니다. 이 설명은 공식 자료에 있는 위험의 예이며 특정 병원에서 버튼이 바뀌었다고 주장하는 사례는 아닙니다.
활성 유형은 페이지 전체와 상호작용하는 리소스입니다. 스크립트와 스타일시트, iframe이나 브라우저에서 실행할 수 있는 다른 코드가 포함됩니다. 공식 설명은 공격자가 이런 내용을 가로채고 다시 작성하면 페이지나 사이트의 동작을 제어하는 데 사용할 수 있다고 안내합니다. 단순히 사진 하나가 달라지는 상태와 코드를 통해 전체 동작에 영향을 주는 상태를 같은 범위로 설명하지 않습니다.
활성 혼합 콘텐츠는 위험이 높아 대부분의 브라우저에서 기본적으로 차단한다고 공식 자료가 설명합니다. 이 동작은 사용자를 보호하기 위한 처리입니다. 화면의 일부 기능이 동작하지 않는 현상을 읽을 때에도 실제로 어떤 리소스가 제한되었는지 이해해야 합니다. 위험한 요청의 차단과 홈페이지에서 의도한 기능의 정상 제공은 서로 다른 상태이므로 화면이 열린 사실만으로 두 상태를 함께 완료했다고 판단하지 않습니다.
web.dev는 수동 혼합 콘텐츠가 있으면 페이지 자체가 HTTPS로 열려도 많은 브라우저의 주소 표시줄에서 안전하지 않은 페이지로 표시할 수 있다고 설명합니다. 주소의 프로토콜과 브라우저가 전체 연결 관계를 바탕으로 전달하는 표시가 다른 대상을 설명하는 것입니다. 시작 문서의 주소가 보안 연결이라는 사실만 읽고 참조 파일의 요청을 제외하면 이러한 표시의 맥락을 이해하기 어렵습니다.
보안 연결과 페이지 경험의 평가
Google의 페이지 경험 안내는 한두 가지 측면에만 몰입하기보다 전반적인 경험을 개선하도록 권고합니다. HTTPS는 연결 상태에 관한 중요한 질문이지만 페이지 이용의 모든 조건을 대신하지 않습니다. 보안 연결을 적용한 뒤에도 사용자가 안내를 읽고 주요 내용을 찾을 수 있는지를 별도로 이해할 이유가 있습니다. 이를 인증서 설치의 효과가 없다는 설명으로 받아들일 필요도 없습니다.
공식 FAQ는 순위 지정에 사용하는 단일 페이지 경험 신호가 없다고 설명합니다. 따라서 HTTPS 상태 하나를 검색엔진이 공개한 종합 점수로 바꾸거나 일정 순위 상승을 약속하는 방식은 근거가 맞지 않습니다. 연결 보안을 개선할 목적과 실제 검색결과를 예측할 목적은 서로 다른 질문입니다.
페이지 경험의 일반적인 평가 단위도 참고할 수 있습니다. Google은 보통 페이지별로 콘텐츠를 평가하지만 사이트 전체 평가도 있다고 설명합니다. 홈페이지의 대표 주소에서 읽은 연결 상태만으로 모든 하위 문서가 같은 조건을 가진다고 확정하기는 어렵습니다. 실제로 설명하려는 안내의 주소가 무엇인지 구별해야 한 페이지의 상태를 사이트 전체의 결과로 확대하지 않습니다.
검색은 페이지 경험이 평균 이하일 때에도 관련성이 가장 높은 콘텐츠를 표시하려고 한다는 설명이 있습니다. 보안 연결을 갖췄다는 사실만으로 독자의 질문에 답하지 못하는 문서가 자동으로 우선된다고 읽지 않습니다. 반대로 특정 페이지가 검색에 보인다고 해서 그 연결 상태와 모든 이용 조건이 이미 좋다고 판정할 수도 없습니다. 검색의 표시와 연결 점검은 같은 종류의 인증이 아닙니다.
보안되지 않은 콘텐츠 요청은 보안 콘텐츠로 바꾸어 페이지가 올바르게 로드되도록 하라는 권고가 web.dev에 있습니다. 이는 주 문서의 주소와 참조 리소스를 함께 판단하는 설명입니다. HTTP에서 HTTPS로 옮기는 전체 이전 작업의 순서와는 구별해야 합니다.
| 보안 연결 외의 경험 질문 | 공식 자체 평가의 대상 | HTTPS만으로 답할 수 없는 조건 |
|---|---|---|
| 휴대기기 표시 | 콘텐츠가 제대로 보이는가 | 작은 화면의 정보 제공 |
| 광고의 방해 | 과도한 광고가 주요 내용을 방해하는가 | 내용을 읽는 이용 환경 |
| 전면 광고 | 접근을 방해하는 요소가 있는가 | 문서를 바로 이용할 조건 |
| 콘텐츠의 구별 | 주요 내용과 다른 내용이 명확한가 | 독자가 읽을 대상의 식별 |
자주 묻는 질문
Chrome이 자동으로 HTTPS로 바꾸면 원본 요청은 괜찮나요?
web.dev는 일부 수동 혼합 콘텐츠가 HTTPS로 제공 가능할 때 Chrome이 보안 버전을 불러올 수 있다고 설명합니다. 보안 버전이 없으면 리소스가 로드되지 않습니다. 자동 처리가 있는 사실만으로 모든 원본 HTTP 요청이 해결되었다고 판단하지 않습니다.
브라우저 경고가 표시되면 위험한 요청보다 항상 먼저인가요?
공식 설명은 혼합 콘텐츠 경고가 이미 보안되지 않은 요청이 실행된 뒤에 나와 늦을 수 있다고 안내합니다. 경고 문구가 보이는 순서와 실제 요청의 실행 순서는 구별해야 합니다. 사용자가 경고를 읽었다는 사실만으로 앞선 통신이 보호되었다고 볼 수 없습니다.
내용이 바뀌지 않았으면 추적 위험도 없는 건가요?
자료는 공격자가 콘텐츠를 변경하지 않아도 혼합 콘텐츠 요청으로 사용자를 추적할 수 있다고 설명합니다. 불러오는 이미지 등 리소스를 바탕으로 방문 페이지나 본 제품을 알 수 있는 조건입니다. 화면의 변경 여부와 요청을 통해 드러나는 정보는 다른 대상입니다.
이전 브라우저에서도 같은 보호 동작을 기대하나요?
web.dev는 공급업체와 버전마다 혼합 콘텐츠 처리 방식이 다르고 이전 버전이 전혀 차단하지 않을 수도 있다고 안내합니다. 한 브라우저의 결과를 모든 방문자의 환경으로 확대하지 않습니다. 실제 사용하는 환경과 요청의 제공 방식을 함께 이해해야 합니다.
브라우저마다 문제를 읽는 위치도 같나요?
공식 자료는 Chrome의 DevTools 문제 탭에서 혼합 콘텐츠와 차단 정보를 읽을 수 있다고 설명합니다. Firefox와 Safari는 콘솔에 메시지를 남긴다고 안내합니다. 한 화면에 메시지가 없다는 사실로 다른 브라우저의 처리 결과까지 같다고 판정하지 않습니다.