如果script-src: hash-source
用於不理解hash-source
的瀏覽器,瀏覽器會忽略所有的script-src:
,甚至是所有的CSP嗎?或者它只會忽略hash-source
部分?Content Security Policy是否兼容?
更一般地說,瀏覽器是否以前向兼容的方式實現CSP?
如果script-src: hash-source
用於不理解hash-source
的瀏覽器,瀏覽器會忽略所有的script-src:
,甚至是所有的CSP嗎?或者它只會忽略hash-source
部分?Content Security Policy是否兼容?
更一般地說,瀏覽器是否以前向兼容的方式實現CSP?
oreoshake關於向後兼容性的陳述是準確的。確定匹配於section 6.6.2.2 of the CSP draft standard被描述的元件的方法:在hash-source
或nonce-source
存在下,unsafe-inline
由符合用戶代理忽略:
源列表允許一個給定類型的所有行內的行爲,如果它包含關鍵字
[...]
如果表達所述隨機數源或散列源語法相匹配,返回「:在下面的算法描述-source表達「不安全內聯」,並且不覆蓋該表達不允許」。
此外,CSP 2指定的parsing a source list with unknown tokens過程如下:
用於通過對空間分割源列表中返回每個令牌,若令牌源表達的語法匹配,則令牌添加到源表達式的集合。
否則,應該忽略它。很明顯,作者意圖至少達到某種程度的向前兼容性。
不理解散列源元素的瀏覽器可能會在控制檯中發出警告,但它們可能並不如此。推薦的方法是使用用戶代理嗅探來檢測支持或發送'unsafe-inline'
與您的散列源值。
理解哈希源的用戶代理將忽略'unsafe-inline'
,那些不會回退到'unsafe-inline'
的用戶代理。所以它是倒退兼容。
感謝您的回覆。我意識到CSP向後兼容的事實,但我想知道它是否也向前兼容,或者如果使用瀏覽器未知的指令,將完全針對該瀏覽器破壞CSP規則。 –