Content-Security-Policy 빌더

지시어별 폼에서 Content-Security-Policy 헤더를 조합합니다. 각 지시어는 공백으로 구분된 소스 목록을 받습니다('self', 'none', 'unsafe-inline' 같은 키워드나 스킴/호스트 소스). 툴은 unsafe-inline, unsafe-eval, 와일드카드가 든 정책을 표시하고, 빈 지시어는 출력에서 빼며, 응답 헤더 형태와 그에 상응하는 <meta> 태그를 함께 내놓습니다(보고 전용 모드에서는 헤더만 내놓습니다. 브라우저는 <meta>로 전달된 보고 전용 정책을 무시하기 때문입니다). 새 정책을 운영에 적용하는 동안에는 보고 전용 모드로 바꿔 쓰면 됩니다.

두 출력 형태는 비슷해 보이지만 동등하지 않습니다. <meta> 태그는 frame-ancestors, report-uri, sandbox를 담을 수 없고, 문서에서 그것이 나타난 지점부터만 효력이 있어서 파서가 이미 지나온 것은 보호되지 않습니다. 응답 헤더에는 그런 제약이 없으므로 서버를 통제할 수 있다면 이쪽을 택하는 것이 맞습니다.

default-src는 하한선이 아니라 대체값입니다. 없는 지시어는 여기서 물려받지만, 직접 쓴 지시어는 해당 자원 종류에 대해 이것을 통째로 대체합니다. 그래서 엄격한 default-src 'self'가 있는 정책에 script-src https://cdn.example.com을 더하면, 'self'를 다시 적지 않는 한 스크립트에 대해서는 'self'가 빠집니다. frame-ancestors와 base-uri를 비롯한 몇몇 지시어는 아예 default-src로 되돌아가지 않으며, 생략하면 그냥 제한이 없습니다.

'unsafe-inline'이 경고를 받는 데는 이유가 있습니다. 대부분의 정책이 존재하는 이유인 그 보호를 꺼 버리기 때문입니다. 또한 nonce나 해시가 든 정책에서는 조용히 무시되는데, 특정 인라인 스크립트를 허용하는 현대적인 방법이 그것이며, 이 상호작용은 정책이 읽히는 것과 다르게 동작하는 흔한 원인입니다.

보고 전용 모드가 올바른 배포 방법입니다. 브라우저가 정책을 평가해 무엇이 깨졌을지 보고하되 아무것도 막지 않으므로, 잊고 있던 제삼자 스크립트와 인라인 핸들러가 드러납니다. 두 헤더가 서로 독립이라는 점은 알아 두십시오. 보고 전용 정책을 내보낸다고 이미 적용 중인 정책이 약해지지 않으며, 그것만으로는 아무것도 강제하지 않습니다.