Ответ 1

Отвечая на Access-Control-Allow-Origin: *, запрашиваемый ресурс разрешает совместное использование с каждым источником. Это в основном означает, что любой сайт может отправить XHR-запрос на ваш сайт и получить доступ к ответам серверов, которые не будут иметь места, если вы не выполнили этот ответ CORS.

Таким образом, любой сайт может отправить запрос на ваш сайт от имени своих посетителей и обработать его ответ. Если у вас что-то реализовано как схема аутентификации или авторизации, основанная на том, что автоматически предоставляется браузером (файлы cookie, сеансы на основе файлов cookie и т.д.), Запросы, инициируемые сторонними сайтами, также будут использовать их.

Это действительно представляет угрозу безопасности, особенно если вы разрешаете совместное использование ресурсов не только для выбранных ресурсов, но и для каждого ресурса. В этом контексте вы должны взглянуть на Когда безопасно включить CORS?.

Ответ 2

Access-Control-Allow-Origin: * абсолютно безопасно добавлять к любому ресурсу, если только этот ресурс не содержит личные данные, защищенные чем-то, кроме стандартных учетных данных (куки, базовая аутентификация, клиентские сертификаты TLS).

Например: данные, защищенные файлами cookie, безопасны

Представьте себе https://example.com/users-private-data, который может предоставлять личные данные в зависимости от состояния пользователя, вошедшего в систему. В этом состоянии используется куки файл сеанса. Можно безопасно добавить Access-Control-Allow-Origin: * к этому ресурсу, так как этот заголовок разрешает доступ к ответу только в том случае, если запрос сделан без файлов cookie, и файлы cookie необходимы для получения личных данных. В результате никакие личные данные не просочились.

Например: данные, защищенные местоположением /ip/внутренней сетью, небезопасны (к сожалению, обычны для интрасетей и бытовой техники):

Представьте себе https://intranet.example.com/company-private-data, который предоставляет данные частных компаний, но к ним можно получить доступ, только если вы находитесь в беспроводной сети компании. Добавлять Access-Control-Allow-Origin: * к этому ресурсу небезопасно, поскольку он защищен с использованием чего-то отличного от стандартных учетных данных. В противном случае плохой сценарий может использовать вас в качестве туннеля для внутренней сети.

Практическое правило

Представьте, что бы увидели пользователи, если бы они обращались к ресурсу в окне инкогнито. Если вы довольны, что все видят этот контент (включая исходный код, полученный браузером), можно добавить Access-Control-Allow-Origin: *.

Ответ 3

AFAIK, Access-Control-Allow-Origin - это просто заголовок http, отправляемый с сервера в браузер. Ограничение его определенным адресом (или отключение) не делает ваш сайт более безопасным, например, для роботов. Если роботы хотят, они могут просто игнорировать заголовок. Обычные браузеры (Explorer, Chrome и т.д.) По умолчанию учитывают заголовок. Но такое приложение, как Postman, просто игнорирует это.

Серверная часть на самом деле не проверяет, что является "источником" запроса, когда возвращает ответ. Он просто добавляет заголовок http. Именно браузер (клиентский конец), который отправил запрос, решает прочитать заголовок контроля доступа и действовать в соответствии с ним. Обратите внимание, что в случае XHR он может использовать специальный запрос "OPTIONS", чтобы сначала запросить заголовки.

Таким образом, любой, кто обладает творческими способностями к написанию сценариев, может легко игнорировать весь заголовок, что бы в нем ни было.

См. Также Возможные проблемы безопасности при настройке Access-Control-Allow-Origin.

Теперь, чтобы действительно ответить на вопрос

Я не могу не чувствовать, что я подвергаю свою среду угрозам безопасности.

Если кто-то хочет напасть на вас, он может легко обойти Access-Control-Allow-Origin. Но, включив "*", вы дадите атакующему еще несколько "векторов атаки", чтобы использовать их, например, используя обычные веб-браузеры, поддерживающие этот заголовок HTTP.

Ответ 4

Вот 2 примера, опубликованных в виде комментариев, когда подстановочный знак действительно проблематичен:

Предположим, я зашел на свой банковский сайт. Если я перехожу на другую страницу и затем возвращаюсь в свой банк, я все еще вошел в систему из-за файла cookie. Другие пользователи в Интернете могут использовать те же URL-адреса в моем банке, что и я, но они не смогут получить доступ к моей учетной записи без файла cookie. Если разрешены перекрестные запросы, вредоносный веб-сайт может эффективно выдать себя за пользователя.

- бред

Предположим, у вас есть обычный домашний маршрутизатор, такой как Linksys WRT54g или что-то еще. Предположим, что маршрутизатор разрешает запросы между источниками. Сценарий на моей веб-странице может отправлять HTTP-запросы на общие IP-адреса маршрутизатора (например, 192.168.1.1) и реконфигурировать ваш маршрутизатор для разрешения атак. Он может даже использовать ваш маршрутизатор напрямую как узел DDoS. (У большинства маршрутизаторов есть тестовые страницы, которые позволяют проверять связь или выполнять простые проверки HTTP-сервера. Они могут быть использованы в массовом порядке.)

- бред

Я чувствую, что эти комментарии должны были быть ответами, потому что они объясняют проблему на примере из реальной жизни.

Ответ 5

Вы используете CORS? Данные, полученные с помощью междоменного запроса AJAX, могут представлять угрозу безопасности для сервера, делающего запрос, но я думаю, что решение для междоменного запроса AJAX предназначено для агента пользователя для реализации синтаксического анализа и/или проверки для известных типов данных внутри XHR в комплекте с обработкой ошибок (очень похоже на то, что делает jQuery.ajax с типом dataType, установленным на "json" ).