SRI는 받은 리소스가 예상한 내용과 일치하는지 확인하며, CORS는 교차 출처 응답을 검사할 수 있는지를 결정합니다.

리소스와 예상 지문을 비교하는 개념도

개념 설명용 이미지이며 실제 해시나 측정 결과를 표시하지 않습니다.

예상한 내용이 검증의 출발점이다

SRI는 스크립트나 스타일시트에 예상 다이제스트를 지정하고 브라우저가 받은 내용과 비교하는 기능입니다. 적용되는 비교에 실패하면 해당 리소스가 거부됩니다. 그러나 불일치가 곧 악성 변조의 증거는 아닙니다. 정상적인 새 버전도 이전 해시와 맞지 않을 수 있습니다. 판단 대상은 선언한 기대와 응답의 일치 여부이지 변경자의 의도나 코드의 안전성 자체가 아닙니다.

기대값을 담은 문서도 신뢰 경계에 포함됩니다. 공격자가 파일뿐 아니라 문서의 다이제스트까지 바꿀 수 있다면 원래 작성자의 기대가 보존되지 않습니다. 해시가 일치하는 코드에도 원하지 않는 동작이 있을 수 있습니다. 이는 내용 동일성을 검사하는 기능에서 도출되는 한계이며, 실제 사고나 전문가 인터뷰를 설명하는 사례가 아닙니다. 기대 내용과 신뢰 경계

알고리즘과 선택된 해시 집합을 읽는다

integrity 표현은 알고리즘과 Base64 다이제스트를 지정합니다. 검증은 인식하는 가장 강한 알고리즘의 집합을 고른 뒤 그 안의 값 하나와 일치하는지 확인합니다. 약한 값의 일치가 강한 집합의 불일치를 구제하지 못합니다. SHA-384는 2016년 권고안에서 논의한 기본 선택이며 유일한 허용 알고리즘은 아닙니다. 선택 규칙

여러 값이 있는 속성을 배포자들의 승인 목록이 아니라 기대값의 집합으로 읽어야 합니다. 가상의 배포에서는 두 값이 허용한 두 파일을 나타낼 수 있습니다. 복사하기 전에 각 값이 어느 파일에 해당하며 왜 두 파일 모두 허용해야 하는지 질문할 수 있습니다. 관계가 불명확하면 값이 늘어난 만큼 배포 설명도 어려워집니다. 이 예는 문서 작성 연습이며 실제 다이제스트나 브라우저 시험 결과를 제시하지 않습니다.

접근 권한과 무결성은 별도 조건이다

동일 출처 응답은 검사 대상이 될 수 있고 교차 출처 응답은 CORS로 읽을 수 있어야 합니다. integrity를 추가한다고 서버 접근 권한이 생기지는 않습니다. 요소의 crossorigin 설정과 서버의 허용 응답을 함께 확인해야 합니다. 기본 클래식 스크립트의 교차 출처 요청에 해시만 붙이는 것으로는 충분하지 않으며 모듈 스크립트에는 자체 CORS 요건도 있습니다. 스크립트 요소

MDN은 anonymous와 use-credentials를 구분합니다. 전자는 다른 출처로 자격 증명을 보내지 않고 후자는 이를 요청합니다. 자격 증명을 포함하는 CORS에는 구체적인 허용 출처와 자격 증명 허용이 필요하며 허용 출처의 별표로 대체할 수 없습니다. 자격 증명 CORS 따라서 anonymous는 흔한 설정이지만 모든 경우에 유일한 선택은 아닙니다. 실제 요청 방식과 응답 헤더를 확인하는 것이 핵심입니다. 요청 자격 증명 방식

파일 변경과 기대값 변경을 함께 관리한다

가상의 배포에서 라이브러리만 갱신하고 페이지에 옛 다이제스트를 남기면 새 파일이 거부될 수 있습니다. 반대로 메타데이터를 먼저 바꾸고 캐시가 옛 파일을 보내도 불일치가 생길 수 있습니다. 두 상황 모두 정상 배포 과정에서 발생할 수 있으며 관찰만으로 공격이라고 진단할 수 없습니다.

검사 대상은 사양이 정의한 리소스 표현이며 콘텐츠 코딩을 처리한 데이터입니다. 특정 브라우저의 메모리 버퍼 구조나 압축된 네트워크 바이트 전체를 그대로 계산한다고 단정하지 않습니다. 최종 배포 파일을 식별하고 페이지의 기대값을 맞추어야 합니다. 자주 바뀌는 파일은 갱신 조정이 필요하지만 무결성 검사가 구조적으로 불가능한 것은 아닙니다. 표현 데이터와 배포

전문적 관점에서 확인할 운영 한계

MDN의 전문 문서는 배포 점검의 관점을 제공합니다. 요소와 URL, 해시, 요청 출처와 자격 증명 방식, 서버의 CORS 허용을 순서대로 확인할 수 있습니다. 정상 일치와 의도적인 불일치를 따로 시험하면 접근 권한 문제와 내용 불일치를 구분하는 데 도움이 됩니다. 거부된 스크립트가 의존 기능에 영향을 줄 수는 있지만 사양이 보장하는 것은 해당 리소스의 거부이며 전체 앱의 장애가 아닙니다.

실패 시 동작과 대체 경로도 판단해야 합니다. 수동 계산이 본질적으로 잘못되었다거나 특정 빌드 도구가 필수라고 주장할 근거는 없습니다. SRI는 신뢰할 수 있는 기대값과 검사 가능한 응답을 전제로 하는 제한된 확인입니다. 코드 검토 등 다른 절차는 다른 문제를 다룹니다. 여기서 설명한 안정된 규칙은 2016년 권고안에 근거하며, 읽은 최신 W3C 주소는 2026년 작업 초안입니다. 새 기능의 보편적 구현을 뜻하지 않습니다. 초안 상태 MDN의 적용 설명

출처