Найдено несколько директив Host — есть ответ « Вопросы и ответы
Вопросы и ответы
Топ за месяц Топ за год Облако тегов Задать вопрос
seo yandex Яндекс СЕО внутренняя сео-оптимизация
mataleao, 584 просмотра
Почему Яндекс выдает мне такую ошибку при проверке robots.txt? Вроде бы он составлен правильно:
User-agent: Yandex
Disallow: /cgi-bin
Disallow: /wp-admin
Disallow: /wp-login.php
Disallow: /wp-register.php
Disallow: /xmlrpc.php
Disallow: /wp-includes
Disallow: /wp-content/plugins
Disallow: /wp-content/cache
Disallow: /wp-content/themes
Disallow: /wp-content/uploads/2012/04/dogovor.doc
Disallow: /hip-young-woman
Disallow: /hello-world-2
Disallow: /hello-contact
Disallow: /wp-content/uploads/2012/04/license.pdf
Disallow: /feed
Disallow: */feed
Disallow: /*?*
Disallow: /*.

Disallow: /*.inc$
Disallow: /*.css$
Disallow: /search/*/feed
Disallow: /search/*/*
Disallow: /tag/
Host: xn--e1af1aeqh.xn--p1ai
Sitemap: http://xn--e1af1aeqh.xn--p1ai/sitemap.xml
User-agent: *
Disallow: /cgi-bin
Disallow: /wp-admin
Disallow: /wp-includes
Disallow: /wp-content/plugins
Disallow: /wp-content/cache
Disallow: /wp-content/themes
Disallow: /wp-content/uploads/2012/04/dogovor.doc
Disallow: /hip-young-woman
Disallow: /hello-world-2
Disallow: /hello-contact
Disallow: /wp-content/uploads/2012/04/license.pdf
Disallow: /wp-trackback
Disallow: /wp-feed
Disallow: /wp-comments
Disallow: */trackback
Disallow: */feed
Disallow: */comments
Host: xn--e1af1aeqh.xn--p1ai
Sitemap: http://xn--e1af1aeqh.xn--p1ai/sitemap.xml
Ответы:
Роман Севко
Неправильно:—
User-agent: Yandex
.

Host: xn--e1af1aeqh.xn--p1ai
Sitemap: http://xn--e1af1aeqh.xn--p1ai/sitemap.xml
10 лет назад
Для ответа необходимо авторизироваться
RPI.su — самая большая русскоязычная база вопросов и ответов. Наш проект был реализован как продолжение популярного сервиса otvety.google.ru, который был закрыт и удален 30 апреля 2015 года. Мы решили воскресить полезный сервис Ответы Гугл, чтобы любой человек смог публично узнать ответ на свой вопрос у интернет сообщества.
Все вопросы, добавленные на сайт ответов Google, мы скопировали и сохранили здесь. Имена старых пользователей также отображены в том виде, в котором они существовали ранее. Только нужно заново пройти регистрацию, чтобы иметь возможность задавать вопросы, или отвечать другим.
Чтобы связаться с нами по любому вопросу О САЙТЕ (реклама, сотрудничество, отзыв о сервисе), пишите на почту [email protected]. Только все общие вопросы размещайте на сайте, на них ответ по почте не предоставляется.
Переезд сайта после отказа от директивы Host — Платон Щукин
Платон Щукин
12 марта 2018, 18:22
В свете отказа от директивы Host я бы хотел рассказать подробнее о рекомендациях по переезду сайта. Данные рекомендации предназначаются как для переезда на протокол https, так и для переезда на новое доменное имя, поскольку алгоритм будет совпадать.
Директива Host позволяла сохранить доступность старого сайта на период переезда, однако ее использование было также сопряжено с некоторыми неудобствами. Например, необходимо было проверять, что в директиве Host всех зеркал указан один и тот же сайт, иначе переезд мог произойти некоректно. В связи с этим было решено отказаться от использования директивы Host — теперь переезд будет выполняться только при помощи редиректа HTTP-301. Это также упростит совмещение переезда в Яндексе и других поисковых системах. Теперь для переезда я рекомендую следующее:
1. Добавьте новый домен в Вебмастер (в том числе сайт по протоколу HTTPS, если переезд выполняется на HTTPS) и убедитесь, что он не склеен в группу зеркал с другим сайтом. Если это так, воспользуйтесь инструментом «Отклейка зеркал», чтобы расклеить сайты. После окончания расклейки переходите ко второму пункту.
2. Настройте редирект 301 со страниц старого сайта на аналогичные страницы нового. При этом я рекомендую учитывать несколько важных моментов:
— сайты должны совпадать между собой структурно, поэтому страницы старого сайта должны выполнять редирект именно на аналогичные страницы нового сайта. Если же структура сайта при переезде изменилась, Вы можете установить редирект со страниц старого сайта на аналогичные страницы нового, а с них установить редирект на нужные адреса. Наши рекомендации по смене структуры сайта описаны в разделе Помощи.
— оба сайта должны быть доступны роботу. Проверьте, что в robots.txt обоих сайтов содержатся одинаковые правила, ведь если будут запрещены разные страницы, это может привести к различию контента. Если сайты используют один и тот же файл robots.txt, то файл sitemap лучше указать по адресу нового главного зеркала, так как после переезда индексироваться будет именно он.
— убедитесь, что большая часть страниц сайтов доступна и отвечает кодом HTTP-200 ОК или кодом редиректа 301. Если на доменах существенная доля страниц будет недоступна из-за кода ответа 404, это может помешать переезду. В таком случае недоступные страницы можно запретить к индексированию в файле robots.txt, чтобы робот-зеркальщик не посещал их при сверке контента.
3. Проверьте, что все зеркала в группе выполняют редирект на желаемое главное зеркало. Это также относиться к версиям «с www» или «без www».
Когда все необходимые настройки будут внесены, в панели Яндекс.Вебмастера старого адреса отправьте заявку на переезд сайта. Если заявка была успешно принята, значит, настройки выполнены корректно и сайты смогут склеиться. Процесс склейки был значительно ускорен и сейчас может занимать от нескольких дней до 3 недель. Замечу, что завершение переезда не означает, что все страницы сайта сразу попадут в поиск по адресу главного зеркала. Страницы неглавного зеркала будут участвовать в поиске какое-то время, пока аналогичные страницы главного зеркала не будут проиндексированы. Постепенно, по мере обхода нужного сайта, неглавное сможет пропасть из поиска.
Зачастую также возникает вопрос, почему в Яндекс.Вебмастере у неглавного зеркала большое число страниц в списке «Загруженных», и это число может даже увеличиваться, хотя в поиске страницы не появляются. В этом нет какой-либо ошибки: в список загруженных входят все страницы, ссылки на которые известны индексирующему роботу, поэтому данные о таких страницах вполне могут храниться в базе робота. Попадать в поиск такие страницы не будут, так как принадлежат неглавному зеркалу.
Не забудьте также, что для нового домена в Яндекс.Вебмастере необходимо добавить свой файл sitemap и установить региональность.
Все блоги сервисов© 2013–2022 «Яндекс»Разделы конфигурации — Apache HTTP Server версии 2.4
Доступные языки: en | фр | я | ко | tr
Директивы в файлах конфигурации могут относиться к
весь сервер, или они могут быть ограничены для применения только к определенным
каталоги, файлы, хосты или URL-адреса. В этом документе описывается, как
используйте контейнеры раздела конфигурации или файлы
.htaccess
изменить область действия других директив конфигурации.
- Типы конфигурации Контейнеры секций
- Файловая система, веб-пространство и логические выражения
- Виртуальные хосты
- Прокси
- Какие директивы разрешены?
- Как объединяются разделы
См. также
- Комментарии
Существует два основных типа контейнеров. Большинство контейнеров
оценивается для каждого запроса. Прилагаемые директивы применяются только
для тех запросов, которые соответствуют контейнерам.
,
и <ЕслиВерсия>
контейнеры, с другой стороны, оцениваются только при запуске сервера
и перезапустите. Если их условия истинны при запуске, то
прилагаемые директивы будут применяться ко всем запросам. Если условия
неверно, вложенные директивы будут игнорироваться.
Директива
содержит директивы, которые будут применяться только в случае соответствующего
параметр определяется в командной строке httpd
. Например,
при следующей конфигурации все запросы будут перенаправлены
на другой сайт, только если сервер запущен с использованием
httpd -DClosedForNow
:Перенаправить "/" "http://otherserver.example.com/"
директива очень похожа, за исключением того, что она содержит директивы, которые
применяться только в том случае, если конкретный модуль доступен на сервере.
Модуль должен быть либо статически скомпилирован на сервере, либо
должен быть динамически скомпилирован, и его строка LoadModule
должна быть раньше в
конфигурационный файл. Эту директиву следует использовать только в том случае, если вам нужно
ваш конфигурационный файл для работы вне зависимости от того, установлены ли определенные модули. установлены. Его не следует использовать для включения директив, которые вы хотите
работать все время, потому что он может подавлять полезные сообщения об ошибках
про отсутствующие модули.
В следующем примере директива MimeMagicFile
будет
применяется, только если mod_mime_magic
доступен.
MimeMagicFile "conf/magic"
очень похожа на
и
, за исключением того, что она содержит директивы, которые
применяться только в том случае, если выполняется конкретная версия сервера. Этот
модуль предназначен для использования в тестовых наборах и больших сетях, которые должны
работать с разными версиями httpd и разными конфигурациями.
<ЕслиВерсия >= 2.4> # это происходит только в версиях больше или # равно 2.4.0.
,
и <ЕслиВерсия>
могут применять отрицательные условия, предваряя их проверку знаком «!».
Наиболее часто используемые контейнеры разделов конфигурации — это
те, которые изменяют конфигурацию определенных мест в
файловая система или веб-пространство. Во-первых, важно понимать,
разница между ними. Файловая система — это вид ваших дисков
как видит ваша операционная система. Например, при установке по умолчанию
Apache httpd находится в /usr/local/apache2
в Unix
файловая система или "c:/Program Files/Apache Group/Apache2"
в
файловая система Windows. (Обратите внимание, что косая черта всегда должна быть
используется в качестве разделителя пути в файлах конфигурации Apache httpd, даже для Windows.) Напротив,
веб-пространство — это представление вашего сайта, предоставленное веб-сервером
и видел клиент. Итак, путь /dir/
в
веб-пространство соответствует пути
/usr/local/apache2/htdocs/dir/
в файловой системе
установка Apache httpd по умолчанию в Unix.
Контейнеры файловой системы
<Каталог>
и <Файлы>
директивы вместе с их регулярными выражениями
контрагентов, применять директивы к
части файловой системы. Директивы, заключенные в раздел
, применяются к
указанный каталог файловой системы и все его подкаталоги
каталог (а также файлы в этих каталогах).
Тот же эффект можно получить с помощью файлов .htaccess. Например, в
После настройки индексы каталогов будут включены для /var/web/dir1
каталог и все подкаталоги.
<Каталог "/var/web/dir1">Опции +Индексы
Директивы, заключенные в секцию
, применяются к любому файлу с
указанное имя, независимо от того, в каком каталоге оно находится.
Так, например, следующие директивы конфигурации будут,
при размещении в основном разделе конфигурационного файла,
запретить доступ к любому файлу с именем private.
независимо
того, где он находится. html
<Файлы "private.html"> Требовать все отказано
Для адресации файлов, найденных в определенной части файловой системы, <Файлы>
и <Каталог>
разделов
можно комбинировать. Например, следующая конфигурация будет запрещать
доступ к /var/web/dir1/private.html
, /var/web/dir1/subdir2/private.html
, /var/web/dir1/subdir3/private.html
и любой другой экземпляр
из private.html
найдено под
/вар/веб/каталог1/
каталог.<Каталог "/var/web/dir1"> <Файлы "private.html"> Требовать все отказано
Контейнеры веб-пространства
<Местоположение>
директива и ее аналог регулярного выражения, на
с другой стороны, изменить
конфигурация контента в веб-пространстве. Например, следующее
конфигурация запрещает доступ к любому URL-пути, начинающемуся с /private. В частности, это будет применяться к запросам на
9/частный»>
Требовать все отказано
директива не должна иметь ничего общего с файловой системой.
Например, в следующем примере показано, как сопоставить конкретный
URL-адрес внутреннего обработчика HTTP-сервера Apache, предоставленный mod_status
.
Файл с именем server-status
не должен существовать в
файловая система.
<Расположение "/сервер-статус"> Статус сервера SetHandler
Перекрывающееся веб-пространство
Чтобы иметь два перекрывающихся URL-адреса, необходимо учитывать порядок, в котором
оцениваются определенные разделы или директивы. За <Расположение>
это будет:
<Расположение "/foo"> <Расположение "/foo/bar">
es с другой стороны,
отображаются наоборот:
Псевдоним "/foo/bar" "/srv/www/uncommon/bar" Псевдоним "/foo" "/srv/www/common/foo"
То же самое верно для ПроксиПасс
директивы:
ProxyPass "/special-area" "http://special.example.com" smax=5 max=10 ProxyPass "/" "balancer://mycluster/" stickysession=JSESSIONID|jsessionid nofailover=On
Подстановочные знаки и регулярные выражения
, <Файлы>
и <Местоположение>
каждая директива может использовать подстановочные знаки в стиле оболочки, как в fnmatch
из стандартной библиотеки C. Персонаж «*»
соответствует любой последовательности символов, «?» соответствует любому одиночному символу,
и «[ seq ]» соответствует любому символу в seq . «/»
символ не будет соответствовать ни одному подстановочному знаку; это должно быть указано
явно.
Если требуется еще более гибкое согласование, каждый
контейнер имеет аналог регулярного выражения (regex)
,
и
, которые позволяют
perl-совместимый
обычные выражения
использовать при выборе спичек. Но см. раздел ниже о
слияние конфигурации, чтобы узнать, как изменится использование разделов регулярных выражений
как применяются директивы.
Раздел подстановочных знаков, не содержащий регулярных выражений, который изменяет конфигурацию все пользовательские каталоги могут выглядеть следующим образом:
Индексы опционов
Используя разделы регулярных выражений, мы можем запретить доступ ко многим типам файлов изображений. сразу:
Требовать все отказано
Регулярные выражения, содержащие именованных групп и обратные ссылки добавляются в среду с соответствующее имя в верхнем регистре. Это позволяет элементам путей к файлам и URL-адреса, на которые можно ссылаться из выражений и модули вроде 9/]+)»> Требовать группу ldap «cn=%{env:MATCH_SITENAME},ou=combined,o=Example»
Логические выражения
директива изменяет конфигурацию в зависимости от условия, которое может быть
выражается логическим выражением. Например, следующая конфигурация
отказывает в доступе, если заголовок HTTP Referer не начинается с
«http://www.example.com/».
<Если "!(%{HTTP_REFERER} -strmatch 'http://www.example.com/*')"> Требовать все отказано
Что использовать Когда
Выбор между контейнерами файловой системы и контейнерами веб-пространства
на самом деле довольно легко. При применении директив к объектам, которые находятся
в файловой системе всегда используйте
или
. При применении директив к объектам
которые не находятся в файловой системе (например, веб-страница, созданная из
базу данных), используйте
.
Важно никогда не использовать
при попытке ограничить
доступ к объектам в файловой системе. Это потому, что многие
разные местоположения веб-пространства (URL) могут отображаться в одной и той же файловой системе.
местоположение, что позволяет обойти ваши ограничения. Например, рассмотрим следующую конфигурацию:
<Расположение "/каталог/"> Требовать все отказано
Это прекрасно работает, если запрос http://yoursite.example.com/dir/
. Но что, если вы находитесь на
файловая система без учета регистра? Тогда ваше ограничение может быть легко
обойти запросом http://yoursite.example.com/DIR/
. Директива
, в
напротив, будет применяться к любому контенту, поданному из этого места,
независимо от того, как это называется. (Исключение составляют ссылки файловой системы.
Один и тот же каталог может быть размещен более чем в одной части
файловая система с использованием символических ссылок.
директива будет следовать за символическим
ссылка без сброса имени пути. Поэтому для высшего уровня
безопасности, символические ссылки должны быть отключены с соответствующими Опции
директива.)
Если вы, возможно, думаете, что ничего из этого к вам не относится
поскольку вы используете файловую систему с учетом регистра, помните, что
многие другие способы сопоставления нескольких местоположений веб-пространства с одним и тем же
расположение файловой системы. Поэтому вы всегда должны использовать файловую систему
контейнеры, когда вы можете. Однако есть одно исключение из этого
правило. Установка ограничений конфигурации в
<Расположение
Раздел "/">
совершенно безопасен, потому что этот раздел будет применяться
ко всем запросам независимо от конкретного URL.
Вложение разделов
Некоторые типы разделов могут быть вложены в другие типы разделов. На одном
рука, <Файлы>
можно использовать
внутри <Каталог>
. На
с другой стороны,
может
использоваться внутри
,
и
разделов (но не внутри другого <Если>
). Регулярное выражение
аналоги именованного раздела ведут себя одинаково.
Вложенные разделы объединяются после невложенных разделов того же типа.
<Виртуальный хост>
container содержит директивы, применимые к конкретным хостам.
Это полезно при обслуживании нескольких хостов с одной машины. с разной конфигурацией для каждого. Чтобы получить больше информации,
см. документацию по виртуальному хосту.
<Прокси>
и
контейнеры применяют только вложенные директивы конфигурации
на сайты, доступ к которым осуществляется через прокси-сервер mod_proxy
которые соответствуют указанному URL. Например, следующая конфигурация
позволит только подмножеству клиентов получить доступ к www.example.com
веб-сайт, использующий прокси-сервер:
<Прокси "http://www.example.com/*"> Требуется хост yournetwork.example.com
Чтобы узнать, какие директивы разрешены в каких типах
разделы конфигурации, проверьте контекст директивы.
Все, что разрешено в <Каталог>
разделы также синтаксически разрешены в
, <Файлы>
, <Соответствие файлов>
, <Расположение>
, <Соответствие местоположения>
, <Прокси>
,
и
разделы. Однако есть некоторые исключения:
- Директива
AllowOverride
работает только в -
FollowSymLinks
иSymLinksIfOwnerMatch
Параметры
работают только в.htaccess
файлов. - Директива
Options
не может использоваться в
Разделы конфигурации применяются в особом порядке. Так как это может иметь важные последствия для того, как директивы конфигурации интерпретируются, важно понимать, как это работает.
Порядок слияния:
-
<Каталог>
(кроме регулярных выражений) и.htaccess
делается одновременно (с.htaccess
, если разрешено, переопределение<Каталог>
) -
<Каталог "~">
) -
-
<Местоположение>
и -
<Если>
Несколько важных замечаний:
- Кроме
Например, запрос /foo/bar будет соответствовать
<Расположение "/foo/bar">
и<Расположение "/foo">
(группа 4 в данном случае): оба раздела будут оцениваться но в том порядке, в котором они указаны в файлах конфигурации. -
<Каталог>
(группа 1 выше) обрабатывается в порядке кратчайшего каталога компонент к самому длинному. Например,<Каталог "/var/web/dir">
будет обработан до<Каталог "/var/web/dir/subdir">
. - Если кратно
<Каталог>
разделов применяются в тот же каталог, в котором они обрабатываются в файле конфигурации заказ. - Конфигурации, включенные с помощью директивы
Include
, будут рассматриваться как они находились внутри включающего файла в месте расположенияВключить директиву
. - разделов внутри
Это позволяет виртуальным хостам переопределить конфигурацию основного сервера.
- Когда запрос обслуживается
mod_proxy
,<Прокси>
контейнер занимает место контейнера
Технические примечания
На самом деле есть <Местоположение>
/ <Соответствие местоположению>
последовательность, выполняемая непосредственно перед фазой перевода имени
(где Псевдонимы
и DocumentRoots
используются для сопоставления URL-адресов с именами файлов). Результаты этого
последовательность полностью отбрасываются после перевода
завершенный.
Взаимосвязь между модулями и разделами конфигурации
Один вопрос, который часто возникает после прочтения разделов конфигурации
слияние связано с тем, как и когда директивы конкретных модулей, таких как mod_rewrite
обрабатываются. Ответ не тривиален и требует немного предыстории.
Каждый модуль httpd управляет своей конфигурацией, и каждая его директива в httpd.conf указывает одну часть
конфигурации в конкретном контексте. httpd не выполняет команду во время ее чтения.
Во время выполнения ядро httpd перебирает определенные разделы конфигурации в порядке описанные выше, чтобы определить, какие из них применимы к текущему запросу. Когда первый раздел совпадает, это считается текущей конфигурацией для этого запроса. Если последующий раздел тоже совпадает, затем каждому модулю с директивой в любом из разделов предоставляется возможность объединить свою конфигурацию между двумя разделами. В результате получается третья конфигурация, и процесс продолжается до тех пор, пока не будут заполнены все разделы конфигурации. оцениваются.
После вышеуказанного шага начинается «настоящая» обработка HTTP-запроса: каждый модуль имеет шанс запуститься
и выполнять любые задачи, которые им нравятся. Они могут получить свою окончательную объединенную конфигурацию из ядра.
httpd, чтобы определить, как они должны действовать.
Пример может помочь визуализировать весь процесс. В следующей конфигурации используется Заголовок
директива mod_headers
установить
определенный HTTP-заголовок. Какое значение будет установлено httpd в CustomHeaderName
заголовок для запроса к /example/index.html
?
<Каталог "/"> Заголовок установить CustomHeaderName один <Соответствие файлов ".*"> Набор заголовков CustomHeaderName три <Каталог "/пример"> Набор заголовков CustomHeaderName два
-
Каталог
«/» соответствует и начальная конфигурация для установки заголовкаCustomHeaderName
со значениемсоздается один
. -
Каталог
«/example» соответствует, и посколькуmod_headers
указывает в своем коде на переопределение в случае слияния, создается новая конфигурация для установки заголовкаCustomHeaderName
со значениемtwo
. -
FilesMatch
«.*» совпадает, и возникает еще одна возможность слияния, в результате чего для заголовкаCustomHeaderName
устанавливается значениеthree
. - В конце концов, на следующих этапах обработки HTTP-запроса будет вызван
mod_headers
, и он получит конфигурацию для установки заголовкаCustomHeaderName
со значениемthree
.mod_headers
обычно использует эту конфигурацию для выполнения своей работы, а именно установки заголовка foo. Это не означает, что модуль не может выполнять более сложные действия, такие как отбрасывание директив, потому что они не нужны или устарели и т. д.
Это верно и для .htaccess, так как они имеют тот же приоритет, что и Каталог
в порядке слияния. Важно понимать, что разделы конфигурации, такие как Directory
и FilesMatch
, несопоставимы с конкретными директивами модуля, такими как Header
или RewriteRule
, поскольку они работают на разных уровнях.
Некоторые полезные примеры
Ниже искусственный пример, показывающий порядок слияние. Предполагая, что все они применимы к запросу, директивы в этот пример будет применяться в порядке A > B > C > D > Д. 9.*б$»> С <Каталог "/a/b"> А
Для более конкретного примера рассмотрим следующее. Независимо от того
любые ограничения доступа, помещенные в разделы
, раздел
будет
оценивается последним и разрешает неограниченный доступ к серверу. В
Другими словами, важен порядок слияния, так что будьте осторожны!
<Расположение "/"> Требовать все предоставленные # Ой! Этот разделне будет иметь никакого эффекта <Каталог "/"> <ТребоватьВсе> Требовать все предоставленные Не требовать размещения badguy.example.com
Content-Security-Policy — HTTP | МДН
Заголовок ответа HTTP Content-Security-Policy
позволяет
администраторам веб-сайта для управления ресурсами, которые пользовательскому агенту разрешено загружать для
данная страница. За некоторыми исключениями, политики в основном включают указание источников серверов и
конечные точки сценария. Это помогает защититься от атак межсайтового скриптинга.
(Межсайтовый_скриптинг).
Дополнительные сведения см. в вводной статье о политике безопасности содержимого (CSP).
Тип заголовка | Заголовок ответа |
---|---|
Запрещенное имя заголовка | нет |
Content-Security-Policy:; <политика-директива>
где
состоит из: <директива> <значение>
без внутренней пунктуации.
Директивы выборки
Директивы выборки управляют местами, из которых могут быть загружены определенные типы ресурсов.
-
дочерний источник
Определяет допустимые источники для веб-воркеров и вложенных контекстов просмотра, загружаемых с использованием таких элементов, как
<кадр>
иПредупреждение: Вместо
child-src
, если вы хотите регулировать вложенные контексты просмотра и рабочие процессы, вы должны использовать директивыframe-src
иworker-src
соответственно.-
коннект-источник
Ограничивает URL-адреса, которые можно загружать с помощью интерфейсов сценариев
-
источник по умолчанию
Служит запасным вариантом для другой выборки директивы.
-
источник шрифта
Указывает действительные источники для шрифтов, загружаемых с использованием
@font-face
.-
кадр-источник
Указывает допустимые источники для загрузки вложенных контекстов просмотра с использованием таких элементов, как
<кадр>
и-
изображение-источник
Указывает допустимые источники изображений и фавиконов.
-
манифест-источник
Указывает допустимые источники файлов манифеста приложения.
-
медиа-источник
Указывает допустимые источники для загрузки мультимедиа с помощью
и
-
объект-источник
Указывает действительные источники для
Примечание: Элементы, контролируемые
object-src
, возможно, по совпадению считаются устаревшими элементами HTML и не получают новые стандартизированные функции (например, атрибуты безопасностипесочница
илиразрешить
дляПоэтому рекомендуется для ограничить эту директиву выборки (например, явно установить
object-src 'none'
, если возможный).-
предварительная выборка-источник
Экспериментальный Указывает допустимые источники для предварительной выборки или предварительного рендеринга.
-
сценарий-источник
Указывает действительные источники для ресурсов JavaScript и WebAssembly.
-
скрипт-источник-элемент
Указывает действительные источники для элементов JavaScript
сценарий-источник-атрибут
Указывает допустимые источники для встроенных обработчиков событий JavaScript.
стиль-источник
Указывает действительные источники для таблиц стилей.
стиль-источник-элемент
Указывает допустимые источники для таблиц стилей
элементов
иэлементов с
rel="stylesheet"
.стиль-источник-атрибут
Указывает допустимые источники для встроенных стилей,применяемых к отдельным элементам DOM.
рабочий-источник
Указывает допустимые источники для
Worker
,SharedWorker
илиСкрипты ServiceWorker
.
Документ директивы
Директивы документа управляют свойствами документа или рабочей среды,к которой применяется политика.применяется.
база-ури
Ограничивает URL-адреса,которые можно использовать в документе
элемент.песочница
Включает песочницу для запрошенного ресурса,аналогичную
песочница
атрибут.
Навигационные директивы
Директивы навигации определяют,в какие места пользователь может перейти или отправить форму,Например.
форма-действие
Ограничивает URL-адреса,которые могут использоваться в качестве цели отправки формы из данный контекст.
фреймы-предки
Указывает действительных родителей,которые могут встраивать страницу,используя
,
,
,
,или
<апплет>
.перейти к
ЭкспериментальныйОграничивает URL-адреса,по которым документ может инициировать навигацию любым способом,в том числе
<форма>
(если не указаноформа-действие
),,
window.
,location
window.open
и т.д.
Указания по отчетности
Директивы по отчетности контролируют процесс отчетности о нарушениях CSP.См.такжеЗаголовок Content-Security-Policy-Report-Only
.
отчет-uri
УстаревшийУказывает пользовательскому агенту сообщать о попытках нарушения политики безопасности контента.Эти отчеты о нарушениях состоят из документов JSON,отправляемых по протоколу HTTP.
Запрос POST
на указанный URI.Предупреждение:Хотя директива
report-to
предназначена заменить устаревшую директивуreport-uri
,Report-To
пока не поддерживается в большинстве браузеров.Итак,для совместимости с текущими браузерами а также добавление прямой совместимости,когда браузеры получают поддержкуReport-To
,можно указать какотчет-uri
иотчет-до
:Content-Security-Policy:…;URI отчета https:
В браузерах,поддерживающих
отчет-до
,директиваreport-uri
будет проигнорирована.отчет по
Запускает событие
SecurityPolicyViolationEvent
.
Другие директивы
требуется шри для
УстаревшийНестандартныйТребуется использование SRI для скриптов или стилей на странице.
требуются доверенные типы для
ЭкспериментальныйПрименяет доверенные типы в приемниках внедрения DOM XSS.
доверенные типы
Устаревшие директивыblock-all-mixed-content
УстаревшийПредотвращает загрузку любых ресурсов с использованием HTTP,когда страница загружается с использованием HTTPS.
типы подключаемых модулей
УстаревшийНестандартныйОграничивает набор подключаемых модулей,которые можно встроить в документ,ограничивая типы ресурсов,которые могут быть загружены.
реферер
УстаревшийНестандартныйИспользуется для указания информации в заголовке Referer(sic)для удаленных ссылок.со страницы.Вместо этого используйте заголовок
Referrer-Policy
.
Обзор допустимых значений приведен ниже.Подробные сведения см.в разделе Исходные значения CSP и документацию по отдельным директивам.
Значения ключевых слов
нет
Не разрешает загрузку любых ресурсов.
самостоятельно
Разрешить ресурсы только из текущего источника.
строго-динамический
Доверие,предоставленное сценарию на странице из-за сопутствующего одноразового номера или хэша,распространяется на загружаемые им сценарии.
образец отчета
Требовать включения образца кода нарушения в отчет о нарушении.
Небезопасные значения ключевого слова
небезопасный встроенный
Разрешить использование встроенных ресурсов.
небезопасная оценка
Разрешить использование динамической оценки кода,например
eval
,setImmediate
Нестандартный.небезопасные хэши
Позволяет включать определенные встроенные обработчики событий.
небезопасно-разрешить перенаправления
ЭкспериментальныйПодлежит уточнению
Значения хостов
- Хост
- Разрешить загрузку ресурсов только с определенного хоста с дополнительной схемой,портом и путем.например
example.com
,*.example.com
,https:
- Части пути в CSP,которые заканчиваются на
/
,соответствуют любому пути,префиксом которого они являются.например
example.com/api/
будет соответствовать URL-адресам типаexample.com/api/users/new
.- Другие части пути в CSP точно совпадают,т.е.
example.com/file.js
будет соответствоватьhttp:
- Части пути в CSP,которые заканчиваются на
- Разрешить загрузку ресурсов только с определенного хоста с дополнительной схемой,портом и путем.например
- Схема
- Разрешить загрузку ресурсов только по определенной схеме,всегда должно заканчиваться"
:
".например,https:
,http:
,данные:
и т.д.
- Разрешить загрузку ресурсов только по определенной схеме,всегда должно заканчиваться"
Другие значения
- nonce-*
Криптографический одноразовый номер(используется только один раз)для разрешения сценариев.Сервер должен генерировать уникальное значение nonce каждый раз,когда он передает политику.Крайне важно предоставить одноразовый номер,который нельзя угадать,поскольку в противном случае обход политики ресурса тривиален.
Это используется в сочетании с атрибутом одноразового номера тега скрипта.например
одноразовый номер-DhcnhD3khTMePgXwdayK9BsMqXjhguVV
- вал*-*
sha256,sha384 или sha512.за которым следует тире,а затем значение sha*.например
sha256-jzgBGA4UWFFmpOBq0JpdsySukE1FrEN5bUpoK8Z29fY=
Рабочие вообщенеуправляются политикой безопасности содержимого документа(или родительского рабочего процесса),создавшего их.К указать политику безопасности контента для воркера,установить
Content-Security-Policy
заголовок ответа для запроса,который запрашивал сам рабочий скрипт.Исключением является случай,когда источником рабочего сценария является глобальный уникальный идентификатор.(например,если его URL-адрес содержит схему данных или большой двоичный объект).В этом случае работник делает наследовать политику безопасности содержимого документа или работника,создавшего его.
Механизм CSP позволяет указать несколько политик для ресурса,в том числе через заголовок
Content-Security-Policy
,Заголовок Content-Security-Policy-Report-Only
и<мета>
элемент.Вы можете использовать заголовок
Content-Security-Policy
более одного раза,как в пример ниже.Обратите особое внимание на директивуconnect-src
здесь.Даже хотя вторая политика разрешает подключение,первая политика содержитconnect-src'нет'
.Добавление дополнительных политикможет только дополнительно ограничитьвозможности защищаемого ресурса,а значит,не будет запрещается подключение и,как самая строгая политика,коннект-источник'нет'
применяется.Content-Security-Policy:default-src'self'http:коннект-источник'нет';Content-Security-Policy:connect-src http:источник сценария http:
Пример:отключить небезопасный inline/eval,разрешить загрузку только ресурсов(изображений,шрифтов,скрипты и т.д.)через https:
Content-Security-Policy:default-src https:
Использование метаэлемента HTML
Пример:уже существующий сайт,который использует слишком много встроенного кода для исправления,но хочет обеспечить ресурсы загружаются только по HTTPS и для отключения плагинов:
Content-Security-Policy:default-src https:'unsafe-eval''unsafe-inline';объект-источник'нет'
Пример:пока не применяйте указанную выше политику;вместо этого просто сообщайте о нарушениях,которые произошло бы:
Content-Security-Policy-Report-Only:default-src https:;отчет-uri/csp-нарушение-отчет-конечная точка/
Дополнительные примеры см.в Руководстве по веб-безопасности Mozilla.
Спецификация Content Security Policy Level 3
#csp-headerтолько с загрузкой таблиц браузера BCD3.