개요
- CSP 헤더 적용을 검토할 때 어디까지 CSP헤더를 추가해야하는가 하는 문제가 있다.
- 예를들면 유저 경험을 위해서 Chrome등의 확장프로그램에서 사용하는 도메인도 추가해야하는가? 하는 문제다.
- 어느정도 조사해보고 정리해둔다.
구글 번역
- 크롬에 내장된(빌트인된) 페이지 번역기능은
translate.googleapis.com를 포함한 몇가지 구글 관련 도메인과 통신한다.
- 그러나 Github나 AWS등 유명한 사이트 몇 개의 CSP 헤더를 검토해본 결과 구글 번역관련 도메인은 허용되어 있지 않았다.
- 그런데도 페이지 번역기능은 잘 동작한다.
- 이건 왜 일까? 아마도 빌트인 기능이기 때문에 CSP의 적용범위를 벗어난 것인지도 모른다. 아니면 CSP의 적용범위더라도 구글이 개발한 Chrome의 기능이기 때문에 같은 구글의 웹 사이트는 CSP에 적용받지 않도록 했는지도 모른다.
- 어쨌든 웹 사이트의 CSP헤더 설정과는 별도로 크롬에서 구글번역은 잘 동작한다. CSP헤더에 구글도메인을 추가할 필요가 없다.
각종 플러그인
- 플러그인에서 사용하는 자바스크립트는 웹 사이트의 CSP헤더의 영향을 받는다.
- 그렇지만 우회할 수 있는 방법이 있다.
- 하나는 플러그인 개발자가 CSP헤더를 우회하는 코드를 넣는 방법이 있다. 여기에 그 방법이 자세히 적혀있다. 간단히 설명하면 개발자가 브라우저의 이벤트 핸들링 코드를 작성하는 부분에서 CSP헤더를 변경하는 방법이다.
- 다른 하나는 사용자측에서 사용하는 방법으로, 웹 사이트의 응답에 포함되어 있는 CSP 헤더를 다시 쓰게 해주는(우회할 수 있게 해주는) 플러그인을 사용하는 것이다. 원리는 아마도 Burp Suite같은 로컬 프록시처럼, 플러그인이 서버와 유저 사이에서 위치해서 CSP 헤더를 변경해주는 것 같다. 여기에서 구할 수 있다.
결론
- 웹 사이트측에서 CSP헤더를 설계할 때 유저가 사용하는 플러그인의 도메인까지 하나하나 추가할 필요는 없을 것 같다. 구글 번역은 CSP헤더에 관련없이 동작하고, 플러그인 개발자는 알아서 플러그인에 필요한 도메인을 실행할 수 있게 만들기 때문이다.
- 애초에 CSP헤더도, 자신의 사이트의 기능을 사용하는데 필요한 도메인을 지정하는게 원래의 사용방법이기도 하다. (유저가 맘대로 설치하는 플러그인은 그 범위는 벗어난 것으로 생각된다.)