SRI(무결성 해시) 적용하기 — 외부 스크립트 변조 막는 방법

1. SRI가 왜 필요한가

1) 외부 스크립트는 편하지만 위험도 함께 따라옵니다

웹사이트를 만들다 보면 jQuery, 분석 도구, 광고 스크립트, 위젯처럼 외부 스크립트를 불러오는 경우가 많습니다. 이런 방식은 개발 속도를 높여주지만, 한편으로는 외부 파일이 바뀌었을 때 그 영향이 그대로 내 사이트에 들어올 수 있다는 점이 문제입니다. 그래서 많은 사람이 SRI설정, integrity해시, 외부스크립트보안, 공급망보안 같은 키워드를 찾게 됩니다. 결국 “내가 직접 관리하지 않는 파일을 어디까지 믿을 수 있나”라는 질문으로 이어지기 때문입니다.

2) 변조된 파일이 그대로 실행되면 사고로 이어질 수 있습니다

외부 CDN이나 서드파티 서버의 스크립트가 공격받거나, 배포 과정에서 실수로 내용이 바뀌는 경우가 있습니다. 이때 브라우저는 특별한 검증 없이 스크립트를 실행할 수 있기 때문에, 사용자의 화면에서 예기치 않은 동작이 발생할 수 있습니다. 특히 결제, 로그인, 폼 입력이 있는 사이트라면 작은 변화도 큰 문제로 이어질 수 있습니다. 이런 이유로 SRI는 단순한 옵션이 아니라 기본적인 공급망보안 수단으로 자주 언급됩니다.

3) 이 글에서는 적용 원리와 체크 포인트를 함께 봅니다

이 글에서는 SRI가 무엇인지, 어떤 상황에서 필요한지, 그리고 실제로 적용할 때 무엇을 주의해야 하는지 정리해보겠습니다. 또한 integrity해시를 어떻게 이해하면 좋은지, 외부스크립트보안 관점에서 어떤 장점이 있는지, 그리고 SRI가 모든 문제를 해결하지는 못한다는 점도 함께 살펴보겠습니다. 마지막에는 어떤 경우에 이런 점검이 특히 유용한지도 정리해드리겠습니다.

2. SRI(무결성 해시)란 무엇인가

1) 브라우저가 파일 변조 여부를 확인하는 방식입니다

SRI는 Subresource Integrity의 약자로, 외부 리소스를 불러올 때 해당 파일이 예상한 내용과 같은지 브라우저가 확인하도록 돕는 기능입니다. 쉽게 말해, “이 파일은 이 해시와 정확히 일치할 때만 실행해도 된다”는 기준을 주는 방식입니다. 여기서 사용하는 값이 바로 integrity해시입니다. 스크립트나 스타일시트가 배포 후에 달라지면 해시 값도 바뀌기 때문에, 브라우저는 일치하지 않는 파일을 차단할 수 있습니다.

2) 해시 값은 파일의 지문처럼 이해하면 됩니다

해시는 파일 내용을 바탕으로 계산되기 때문에, 아주 작은 수정만 있어도 결과가 완전히 달라집니다. 그래서 SRI설정은 외부 파일이 원래 의도한 버전인지 확인하는 데 적합한 편입니다. 예를 들어 CDN에 올라간 파일이 예기치 않게 바뀌거나, 중간 경로에서 내용이 수정되는 상황을 감지하는 데 도움이 됩니다. 이런 점에서 SRI는 “다운로드한 파일을 믿어도 되는가”를 확인하는 최소한의 장치라고 볼 수 있습니다.

3) 외부 리소스 전체를 보호하는 것은 아닙니다

다만 SRI가 있다고 해서 모든 보안 문제가 해결되는 것은 아닙니다. 적용 대상은 주로 외부에서 불러오는 스크립트나 스타일처럼, 해시를 미리 고정할 수 있는 파일입니다. 반대로 서버에서 동적으로 생성되는 파일이나 자주 바뀌는 리소스는 관리가 까다로울 수 있습니다. 따라서 SRI는 외부스크립트보안의 핵심 도구 중 하나이지만, 다른 보안 설정과 함께 보는 것이 좋습니다.

3. 어떤 상황에서 SRI설정이 특히 중요할까

1) CDN에서 라이브러리를 불러올 때

많은 사이트가 성능과 편의성을 이유로 CDN을 사용합니다. 하지만 CDN에 있는 파일은 내가 직접 배포하지 않는 만큼, 내용 변경 가능성을 완전히 배제할 수 없습니다. 이럴 때 SRI설정을 해두면 파일이 예상과 다를 경우 브라우저가 실행을 막을 수 있습니다. 특히 인기 있는 라이브러리나 공용 스크립트는 공급망보안 관점에서 한 번 더 점검할 가치가 있습니다.

2) 마케팅·분석·광고 스크립트를 삽입할 때

외부 추적 스크립트는 기능상 필요할 수 있지만, 동시에 사이트 성능이나 보안에 영향을 줄 수도 있습니다. 만약 해당 파일이 변경되었는데도 그대로 로드된다면, 의도하지 않은 코드가 함께 실행될 수 있습니다. 이런 경우 integrity해시를 사용하면 최소한 “예상한 버전만 허용한다”는 기준을 둘 수 있습니다. 외부 의존성이 많은 사이트일수록 이런 습관이 중요합니다.

3) 보안 사고가 민감한 서비스일수록 더 중요합니다

로그인, 회원가입, 결제, 개인정보 입력처럼 민감한 화면이 포함된 서비스라면 외부스크립트보안에 더 신경 써야 합니다. 외부 자바스크립트 한 줄이 사용자 신뢰에 직접적인 영향을 줄 수 있기 때문입니다. 물론 SRI만으로 모든 위험을 막을 수는 없지만, 최소한의 방어선 역할은 해줍니다. 이런 이유로 보안 점검 과정에서 SRI는 자주 체크되는 항목입니다.

4. SRI설정은 어떻게 동작할까

1) integrity 속성에 해시를 넣습니다

SRI를 적용할 때는 <script> 또는 <link> 태그에 integrity 속성을 추가합니다. 여기에 SHA-256, SHA-384, SHA-512 같은 방식으로 생성된 해시 값을 넣습니다. 브라우저는 리소스를 받아온 뒤 실제 파일 내용으로 다시 해시를 계산하고, 속성 값과 비교합니다. 값이 다르면 해당 리소스를 실행하지 않습니다.

2) crossorigin 속성과 함께 쓰는 경우가 많습니다

외부 도메인에서 리소스를 가져오는 경우에는 crossorigin 설정이 함께 필요한 경우가 있습니다. 특히 CORS 정책과 맞물려 브라우저가 정상적으로 파일을 확인해야 하기 때문입니다. 따라서 SRI설정을 할 때는 단순히 해시만 추가하면 끝나는 것이 아니라, 파일을 불러오는 방식까지 함께 살펴봐야 합니다. 이 부분을 놓치면 “해시를 넣었는데도 동작하지 않는다”는 상황이 생길 수 있습니다.

3) 해시가 바뀌면 다시 생성해야 합니다

외부 파일이 업데이트되면 기존 integrity해시는 더 이상 맞지 않습니다. 이 경우 브라우저는 파일을 차단하므로, 개발자는 새 파일 기준으로 해시를 다시 만들어야 합니다. 즉 SRI는 한 번 넣고 끝나는 설정이 아니라, 배포와 함께 관리해야 하는 항목입니다. 자주 바뀌는 파일이라면 운영 방식까지 함께 고민하는 편이 좋습니다.

5. SRI 적용 시 주의할 점

1) 빈번하게 바뀌는 파일에는 관리 부담이 생깁니다

SRI는 고정된 버전의 파일에 특히 잘 맞습니다. 반면 외부 제공자가 자주 업데이트하는 파일은 해시를 계속 수정해야 하므로 운영이 번거로워질 수 있습니다. 이런 파일은 버전 고정이 가능한지 먼저 확인하는 편이 좋습니다. 그렇지 않으면 SRI설정이 오히려 배포 작업의 변수가 될 수 있습니다.

2) 해시가 맞지 않으면 기능이 깨질 수 있습니다

보안상으로는 차단이 맞지만, 실무에서는 기능 중단으로 이어질 수 있습니다. 예를 들어 외부 라이브러리가 로드되지 않으면 버튼 동작이나 화면 렌더링이 정상 작동하지 않을 수 있습니다. 그래서 SRI는 “적용하면 무조건 좋다”기보다, 서비스 중요도와 배포 구조를 함께 고려해 도입하는 편이 적합합니다. 특히 운영 중인 사이트는 테스트 후 적용하는 것이 안전합니다.

3) SRI만으로 공급망 공격을 모두 막지는 못합니다

SRI는 파일이 바뀌었는지 확인하는 데 유용하지만, 처음부터 공격자가 신뢰된 소스 자체를 장악한 경우까지 완전히 해결해주지는 못합니다. 또 HTML 문서 자체가 변조되면 잘못된 해시가 함께 배포될 수도 있습니다. 그래서 공급망보안은 SRI 하나만이 아니라, 배포 권한 관리, CSP, 패키지 검증, 코드 리뷰 같은 여러 요소와 함께 보는 것이 좋습니다. SRI는 그중에서도 브라우저 레벨의 기본 방어선에 가깝습니다.

6. 외부스크립트보안을 넓게 보면 무엇을 함께 봐야 할까

1) 보안 헤더와 함께 점검하는 것이 좋습니다

외부스크립트보안은 단순히 해시를 넣는 것에서 끝나지 않습니다. 보안 헤더, HTTPS, 쿠키 설정, CORS 정책 등도 함께 확인해야 실제 위험을 줄일 수 있습니다. 예를 들어 Mixed Content가 있으면 HTTPS 페이지에 HTTP 자원이 섞여 들어와 보안이 약해질 수 있습니다. 이런 기본 설정을 정리해두면 SRI의 효과도 더 안정적으로 활용할 수 있습니다.

2) API 키와 환경 변수 노출도 함께 확인해야 합니다

외부 스크립트뿐 아니라 .env 파일, 소스코드, API 키 노출도 실제 사고로 이어질 수 있는 항목입니다. 브라우저에서 보이는 코드나 네트워크 요청에 민감한 정보가 남아 있지 않은지 점검하는 습관이 필요합니다. 이런 부분은 도구를 통해 빠르게 확인할 수 있는데, URL을 넣어 기본 보안 상태를 점검하는 방식이 특히 유용한 편입니다. 외부스크립트보안과 정보 노출 점검은 함께 보는 것이 좋습니다.

3) 실사용 환경에서의 동작 확인이 중요합니다

로컬 개발 환경에서는 문제없어 보이던 설정이 운영 서버에서는 다르게 동작하는 경우가 있습니다. 특히 CDN, 캐시, 브라우저 정책이 결합되면 예상하지 못한 오류가 생기기도 합니다. 따라서 SRI설정을 적용했다면 실제 브라우저에서 스크립트가 차단되는지, 경고가 뜨는지, 기능이 정상 동작하는지까지 확인하는 것이 좋습니다. 이런 점검이 곧 공급망보안의 실무적인 출발점이 됩니다.

7. SRI를 도입하면 어떤 점이 달라질까

1) 최소한의 안전장치를 마련할 수 있습니다

SRI는 거대한 보안 체계를 대신하는 도구는 아니지만, 외부 파일이 예상과 다를 때 브라우저가 이를 막아준다는 점에서 의미가 큽니다. 특히 CDN 의존도가 높거나 서드파티 스크립트를 많이 쓰는 사이트라면 효과를 체감하기 쉽습니다. 무엇보다 integrity해시를 기준으로 파일을 검증한다는 점에서, 보안 관리의 기준선을 세우는 데 도움이 됩니다. 작은 설정처럼 보여도 실제 사고 예방에는 꽤 중요한 역할을 할 수 있습니다.

2) 개발과 운영의 기준이 더 명확해집니다

SRI설정을 도입하면 “어떤 외부 파일을 허용할 것인지”가 분명해집니다. 이는 보안뿐 아니라 운영 측면에서도 장점이 있습니다. 파일 변경 시점과 배포 기준이 명확해지고, 의도하지 않은 변경을 빨리 발견할 수 있기 때문입니다. 이런 점에서 SRI는 단순한 기능 추가가 아니라 관리 기준을 정리하는 과정으로 볼 수 있습니다.

3) 이런 상황이라면 검토해볼 만합니다

외부 라이브러리를 자주 불러오는 사이트, 로그인이나 결제처럼 민감한 기능이 있는 서비스, 또는 공급망 공격 가능성을 미리 줄이고 싶은 프로젝트라면 SRI 도입을 검토해볼 만합니다. 특히 “외부에서 가져온 스크립트가 변조되면 어떻게 하지?”라는 고민이 있다면 외부스크립트보안 관점에서 우선순위가 높습니다. 마지막으로 정리하면, SRI는 외부 스크립트 변조를 막는 데 유용한 기본 수단이며, 직접 전화하듯 즉시 확인하고 조치하는 방식과 달리 자동으로 파일 무결성을 검증해준다는 점이 차이입니다. 그래서 반복적으로 외부 리소스를 쓰는 환경일수록 SRI설정, integrity해시, 공급망보안을 함께 고려하는 편이 더 안정적입니다.