1

От чтения CSP Standard specification and examples кажется, что он не поддерживает подстановочные знаки в части пути для данного URL. Это похоже на надзор, так как многие CDN и статические хостинг-провайдеры совместно используют имена корневых доменов между своими пользователями и только дифференцируют доступ по URL-адресам, а не по всему домену.Поддерживает ли стандарт политики безопасности содержимого шаблоны подстановочных знаков? Если нет, то почему?

Например, при использовании S3 или Google Cloud Storage в качестве CDN вы можете захотеть, чтобы CSP позволял загружать сценарии/активы из вашего ведра с помощью подстановочного URL, такого как «https://storage.googleapis.com/my-apps-bucket/ *», но запретить их для остальных от https://storage.googleapis.com, так как для злоумышленника было бы довольно тривиально создавать свою собственную учетную запись и обслуживать контент из этого корневого домена.

Это похоже на довольно распространенный случай использования, я не понимаю, что такое spec? Если нет, то какой синтаксис использовать подстановочные пути, поскольку использование заголовка, такого как Content-Security-Policy: script-src 'self' https://example.com/*, похоже, не работает.

ответ

5

В разделе «Сопоставление исходных выражений» часть спецификации (http://www.w3.org/TR/CSP/#match-source-expression) подробно описывает алгоритм сопоставления URL-адресов. Он поддерживает то, о чем вы просите, но вы не используете символ подстановки.

Спецификация обсуждает необязательную «часть пути» разрешенных источников и говорит, что если разрешенный URL-адрес заканчивается косой чертой «/», то это префиксное совпадение, а не точное совпадение.

Таким образом, в вашем примере, если вы позволите

https://storage.googleapis.com/my-apps-bucket/ 

с косой чертой, но без звездочки на конце, он будет соответствовать файлы ниже этого URL, например

https://storage.googleapis.com/my-apps-bucket/file1.js