완전한 설명을 원하는 사람이라면 콘텐츠 보안 정책 ( https://www.html5rocks.com/en/tutorials/security/content-security-policy/)을 살펴 보시기 바랍니다 .

에서 “코드 https://mybank.com은 단지에 액세스 할 수 있어야한다
https://mybank.com 의 데이터를, 그리고 https://evil.example.com 확실히 액세스를 허용해서는 안됩니다. 각각의 기원이 분리 유지 나머지 웹 “

XSS 공격은 브라우저가 다른 웹 사이트에서 다운로드 한 코드와 앱의 코드를 구별 할 수 없기 때문에 발생합니다. 따라서 Content-Security-PolicyHTTP 헤더를 사용하여 콘텐츠를 안전하게 다운로드 할 수있는 콘텐츠 원본을 화이트리스트에 추가해야합니다 .

이 정책은 일련의 정책 지시문을 사용하여 설명되며, 각 지시문은 특정 리소스 유형 또는 정책 영역에 대한 정책을 설명합니다. 정책에는 자체 정책이 없을 때 다른 리소스 유형에 대한 대비책 인 default-src 정책 지시문이 포함되어야합니다.

따라서 태그를 다음과 같이 수정하면

<meta http-equiv="Content-Security-Policy" content="default-src 'self' data: gap: https://ssl.gstatic.com 'unsafe-eval'; style-src 'self' 'unsafe-inline'; media-src *;**script-src 'self' http://onlineerp.solution.quebec 'unsafe-inline' 'unsafe-eval';** ">

당신은 Javacsript 코드 (실행 권한을 부여하는 것을 말하는 script-src기원에서)를 'self', http://onlineerp.solution.quebec, 'unsafe-inline', 'unsafe-eval'.

처음 두 가지는 귀하의 사용 사례에 대해 완전히 유효하다고 생각하지만 다른 사례에 대해서는 약간 확신이 없습니다. 'unsafe-line'그리고 'unsafe-eval'당신이 그들에 대한 매우 구체적인 필요가 없다면 당신이 그들을 사용하지 않아야하므로 보안 문제가 포즈 :

“eval 및 text-to-JavaScript 형제가 응용 프로그램에 완전히 필수적인 경우 script-src 지시문에 허용 된 소스로 ‘unsafe-eval’을 추가하여 활성화 할 수 있습니다. 그러나 다시 말하지 마십시오. 문자열을 실행할 수있는 능력은 공격자가 귀하의 사이트에서 승인되지 않은 코드를 실행하는 것을 훨씬 더 어렵게 만듭니다. ” (Mike West, Google)