서드파티 스크립트 및 SRI 감사

사이트의 벤더 스크립트가 바뀌거나 중단될까 걱정되나요? myeventwatch로 무료 모니터링 — 만료 및 다운타임 알림, 카드 불필요.

이 감사가 확인하는 것 — 그리고 볼 수 없는 것

체커는 페이지를 한 번 가져와 제공받은 HTML — 정적 HTML만 — 을 파싱합니다. 그 마크업 안의 모든 <script src>는 호스트와 함께 나열되고, 호스트가 페이지의 등록 가능 도메인과 일치하면 퍼스트파티로, 그렇지 않으면 서드파티로 분류되며, 브라우저가 당신을 보호할 수 있는지를 결정하는 두 속성, 즉 integrity(브라우저가 파일 실행 전에 검증하는 SRI 해시)와 crossorigin(교차 출처 SRI 검사가 작동하는 데 필요한 속성)을 확인합니다. URL 안의 버전도 평가됩니다: [email protected]이나 /v2.4/로 주소가 지정된 스크립트는 고정된 것이고, latest나 버전이 없는 주소는 아무도 당신의 사이트를 건드리지 않아도 언제든 내용이 바뀔 수 있는 움직이는 표적입니다.

경계를 분명히 하세요. 중요하기 때문입니다: v1은 페이지의 정적 HTML만 파싱합니다 — JavaScript가 런타임에 주입하는 스크립트는 포함되지 않습니다. 태그 관리자, 동의 도구, 채팅 위젯은 페이지가 로드된 뒤 코드에서 script 요소를 만드는 일이 흔하며, 정적 파싱은 그것들을 결코 보지 못합니다. 이 감사를 템플릿과 CMS가 직접 참조하는 것들의 목록 — 보통 문제에서 가장 크고 가장 고치기 쉬운 부분 — 으로 취급하고, 태그 관리자 컨테이너는 관리자 자체의 미리보기와 변경 이력에서 따로 감사하세요. 인라인 스크립트(src가 없는 블록)는 SRI를 전혀 가질 수 없으므로 결과에 사실로 셉니다. 동반 가이드가 그것들을 어떻게 다룰지 설명합니다.

해시 열: 계산된 것이지, 결코 추측이 아닙니다

integrity 속성이 부족한 서드파티 스크립트에 대해서는, 체커가 스크립트 자체를 가져옵니다 — 이 사이트의 모든 체커와 같은 SSRF 방어 가져오기 경로를 통해, 해당 스크립트 중 처음 15개, 각각 512 KB까지 — 그리고 그 SHA-384 해시를 계산합니다. 가져오기가 성공하면 SRI 셀에는 전체 스니펫 integrity="sha384-…"가 표시되어 crossorigin="anonymous"와 나란히 태그에 붙여넣을 준비가 됩니다. 해시는 스크립트가 실제로 가져와졌을 때만 표시됩니다. 가져오기가 실패했거나, 파일이 너무 컸거나, 스크립트가 15개 상한을 넘어섰다면, 셀에는 대신 그 메모가 표시됩니다 — 자리 표시자나 추측값은 결코 표시되지 않습니다 — 그리고 해결책은 정확한 파일이 손에 있는 당신 자신의 빌드 파이프라인에서 해시를 생성하는 것입니다.

관련 검사: 보안 헤더 검사는 응답 헤더를 채점합니다 — SRI의 자연스러운 파트너인 Content-Security-Policy를 포함합니다 —, SSL 채점기는 그 스크립트들이 도착하는 전송 경로를 다루고, 동반 글 서드파티 스크립트는 공급망 리스크입니다는 실제 사건, SRI가 막는 것과 막지 못하는 것, 반복 가능한 감사 루틴을 살펴봅니다.

판정은 이렇게 읽어야 합니다: 무결성이 있고 버전이 고정된 서드파티 스크립트가 건강한 경우입니다 — 브라우저는 교체되거나 편집된 파일을 거부할 것입니다. 무결성이 없는 서드파티 스크립트는 자동으로 악성인 것은 아닙니다. 보호되지 않는다는 뜻으로, 그 내용은 호스트가 오늘 제공하는 것이 무엇이든 그것이며, 변경에 대한 유일한 경고는 피해 그 자체가 될 것입니다. 고정되지 않은 주소는 부족한 해시와 같은 의심을 받아야 합니다. latest URL 위의 SRI 해시는 벤더가 첫 업데이트를 배포하는 순간 깨지기 때문입니다 — 그래서 두 발견은 나란히 보고되고, 그래서 오래가는 해결책은 항상 쌍입니다: 먼저 정확한 버전을 고정하고, 그 다음 바로 그 파일의 해시를 구하세요.

이 페이지가 보여 주는 사실

자주 묻는 질문