Это предотвращает раскрытие ответа через угон JSON.

Теоретически содержимое HTTP-ответов защищено одной и той же политикой происхождения: страницы из одного домена не могут получать какие-либо фрагменты информации со страниц из другого домена (если это явно не разрешено).

Злоумышленник может запрашивать страницы в других доменах от вашего имени, например, используя тег <script src=...> или <img>, но он не может получить никакой информации о результате (заголовки, содержимое).

Таким образом, если вы посетите страницу злоумышленника, он не сможет прочитать вашу электронную почту с gmail.com.

За исключением того, что при использовании тега сценария для запроса содержимого JSON JSON выполняется как Javascript в контролируемой среде злоумышленника. Если злоумышленник может заменить конструктор Array или Object или какой-либо другой метод, используемый во время создания объекта, все, что в JSON, пройдет через код злоумышленника и будет раскрыто.

Обратите внимание, что это происходит во время выполнения JSON как Javascript, а не во время его анализа.

Есть несколько контрмер:

Убедитесь, что JSON никогда не выполняется

Поместив оператор while(1); перед данными JSON, Google гарантирует, что данные JSON никогда не выполняются как Javascript.

Только законная страница может получить весь контент, удалить while(1); и проанализировать остаток как JSON.

Такие вещи, как for(;;); были замечены на Facebook, например, с такими же результатами.

Убедитесь, что JSON не является допустимым Javascript

Точно так же добавление недопустимых токенов перед JSON, например &&&START&&&, гарантирует, что он никогда не будет выполнен.

Всегда возвращайте JSON с Объектом снаружи

Это OWASP рекомендуемый способ защитить от взлома JSON и является менее навязчивым.

Подобно предыдущим контрмерам, он гарантирует, что JSON никогда не выполняется как Javascript.

Допустимый объект JSON, если он ничем не заключен, недопустим в Javascript:

eval('{"foo":"bar"}')
// SyntaxError: Unexpected token :

Однако это действительно JSON:

JSON.parse('{"foo":"bar"}')
// Object {foo: "bar"}

Итак, убедитесь, что вы всегда возвращаете Object на верхнем уровне ответа, убедитесь, что JSON не является допустимым Javascript, но при этом остается действительным JSON.

Как отмечает @hvd в комментариях, пустой объект {} является допустимым Javascript, и знание того, что объект пуст, само по себе может быть ценной информацией.

Сравнение вышеуказанных методов

Способ OWASP менее навязчив, так как не требует изменений клиентской библиотеки и передает действительный JSON. Однако неясно, могут ли прошлые или будущие ошибки браузера победить это. Как отмечает @oriadam, неясно, могут ли данные быть пропущены в результате ошибки синтаксического анализа при обработке ошибок или нет (например, window.onerror).

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

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

Это сделано для того, чтобы какой-то другой сайт не мог делать неприятные трюки, пытаясь украсть ваши данные. Например, заменив конструктор массива, а затем включив этот URL-адрес JSON через {{ X0}}, злонамеренный сторонний сайт может украсть данные из ответа JSON. Поместив while(1); в начало, скрипт будет зависать.

С другой стороны, запрос на том же сайте с использованием XHR и отдельного анализатора JSON может легко игнорировать префикс while(1);.

Примечание : с 2019 года многие из старых уязвимостей, которые приводят к профилактическим мерам, обсуждаемым в этом вопросе, больше не являются проблемой в современных браузерах. Я оставлю ответ ниже как историческое любопытство, но на самом деле вся тема радикально изменилась с 2010 года (!!), когда об этом спросили.

Он не позволяет использовать его в качестве цели простого тега <script>. (Ну, это не мешает этому, но делает его неприятным.) Таким образом, плохие парни не могут просто разместить этот тег сценария на своем собственном сайте и полагаться на активный сеанс, чтобы сделать возможным получение вашего контента.

изменить - обратите внимание на комментарий (и другие ответы). Проблема связана с извращенными встроенными средствами, в частности с конструкторами Object и Array. Они могут быть изменены таким образом, чтобы в противном случае безобидный JSON при анализе мог вызвать код злоумышленника.

Это может затруднить вставку ответа JSON в документ HTML с тегом <script>. Помните, что тег <script> освобождается от Одинаковой политики происхождения.

После проверки подлинности защита от угона JSON может занять разнообразие форм. Google добавляет while (1) в свои данные JSON, поэтому что если какой-либо вредоносный скрипт его оценивает, бесконечный цикл.

Ссылка: Справочник по тестированию веб-безопасности: систематические методы быстрого поиска проблем

Поскольку тег <script> освобожден от той же политики происхождения, что является необходимостью безопасности в веб-мире, while(1) при добавлении в ответ JSON предотвращает его неправильное использование в теге <script>.