CSP 해시 생성기

인라인 스크립트나 스타일의 내용을 그대로 붙여 넣으면, Content-Security-Policy가 허용 목록 항목으로 받아들이는 'sha256-…' 토큰이 나옵니다. CSP에서는 SHA-256, SHA-384, SHA-512가 모두 유효합니다. 해시는 UTF-8 바이트에 대해 계산한 뒤 base64로 인코딩되는데, 브라우저가 파싱 시점에 비교하기 전에 하는 일과 정확히 같습니다.

바이트 단위 비교이기 때문에 바이트를 바꾸는 모든 것이 해시를 바꿉니다. 요소의 텍스트 내용만 붙여 넣으세요. <script> 태그도, 실제로는 존재하지 않는 주변 들여쓰기도 넣으면 안 됩니다. CRLF 줄바꿈으로 저장된 파일은 같은 내용을 LF로 저장한 파일과 해시가 다르고, 편집기가 조용히 덧붙인 마지막 줄바꿈 하나도 CSP에게는 다른 스크립트입니다. 확실하다고 생각한 해시가 맞지 않는다면, 범인은 거의 언제나 양 끝의 공백이거나 빌드 어딘가의 줄바꿈 변환입니다.

해시 계산보다 사람들을 더 놀라게 하는 정책 차원의 동작이 하나 있습니다. script-src에 해시나 논스를 하나라도 추가하면 브라우저는 같은 지시문 안의 'unsafe-inline'을 무시합니다. 그 대체 값은 해시를 이해하지 못하는 구형 브라우저를 위해서만 남아 있습니다. 그러니 해시를 "추가로" 적어 두고 인라인 스크립트도 계속 돌아가게 할 수는 없습니다. 첫 해시가 등장하는 순간, 모든 인라인 스크립트에 해시가 필요해집니다. 이것이 의도된 이행 경로이고, 해시를 절반만 도입한 정책이 1분 전까지 잘 되던 페이지를 망가뜨리는 이유이기도 합니다.

해시가 모든 인라인을 덮을 수 있는 것도 아닙니다. onclick= 속성과 javascript: URL도 인라인 스크립트이지만 텍스트 내용을 가진 요소가 아니므로 어떤 해시와도 맞지 않습니다. CSP 레벨 3이 바로 그 경우를 위해 'unsafe-hashes'를 추가했는데, 이름 자체가 충분한 경고입니다. 가능하다면 핸들러를 해시가 걸린 스크립트 블록 안으로 옮기세요. 이 생성기는 웹 크립토 API를 통해 전적으로 브라우저 안에서 동작하므로, 아직 공개할 준비가 되지 않은 스크립트가 해시를 낸다고 해서 공개되지는 않습니다.