Код
<?php echo $_GET['name']; ?>
публикует в ответе значение, пришедшее от пользователя, без какой‑либо обработки. Это классический пример уязвимости типа Cross‑Site Scripting (XSS) — в данном случае обычно отражённый (reflected) XSS, если значение берётся напрямую из GET и моментально выводится в ответ.

Что это даёт злоумышленнику — возможные последствия

Выполнение произвольного JavaScript в контексте сайта и домена жертвы.Кража cookies (если они не помечены HttpOnly), токенов в localStorage/sessionStorage, CSRF‑токенов, личных данных.Выполнение действий от лица пользователя (например, отправка форм), подмена содержимого страницы (фишинг), перехват вводимых данных (кейлоггер), перенаправление на вредоносные сайты, майнинг в браузере и пр.Для сайтов с правами администраторов — полный компромисс аккаунтов/панелей управления.В более редких случаях — обход CSP/каких‑то других политик, или доведение до RCE на сервере при дальнейшей неосторожной работе с внедрёнными данными.

Контексты вывода и примеры атак
1) Текстовый (HTML body/text node)
Пример уязвимого шаблона:

Hello, <?php echo $_GET$${}^{\prime }nam{e}^{\prime }$$; ?>

Если в name передать alert$1$, скрипт выполнится.

2) Атрибуты HTML
link

Если атрибут не экранирован или используются одиночные/двойные кавычки неправильно — можно «вырваться» из кавычек и вставить onmouseover=… или javascript:alert(1).
Пример полезной нагрузки: " onmouseover="alert(1)" x="

3) JavaScript‑контекст (внутри )

var name = '<?php echo $_GET$${}^{\prime }nam{e}^{\prime }$$; ?>';Если строка не экранирована, можно закончить строковый литерал и вставить произвольный код, например: ');evil;//Безопаснее: использовать json_encode для вставки литерала JS: var name = <?php echo json_encode($name); ?>;

4) URL/href контекст

Вставка javascript: или data: URI может привести к выполнению кода, если браузер позволит.

5) CSS контекст $внутри<style>илиstyle=$

Можно вставить expression $встарыхIE$, url$javascript:...$ и т.п.

6) Другие контексты: атрибуты состояний, комментарии, XML/JSON — в каждом случае нужны специфические меры экранирования.

Как защищаться $сервернаясторона$ 1) Выходное кодирование $primarydefense$

Всегда экранировать данные перед выводом в ответ в зависимости от контекста:
HTML текст: htmlspecialchars($val, ENT_QUOTES | ENT_SUBSTITUTE, 'UTF-8')HTML атрибут: тоже htmlspecialchars с ENT_QUOTES $изаключатьатрибутвкавычки$JavaScript: использовать json_encode($val) при встраивании в JS как литерал
Пример: var name = <?php echo json_encode($name, JSON_UNESCAPED_UNICODE); ?>;URL: rawurlencode($val) или filter_var($val, FILTER_VALIDATE_URL) + безопасная нормализацияCSS: избегать динамического вставления в CSS; при необходимости использовать специализированное экранированиеПравило: кодируйте при выводе, не при вводе.

2) Валидация и белый список

По возможности ограничивать входные данные по типу/формату/длине (например, имя — только буквы, длина < 100).Для URL — проверять схему $http/https$ и домен/путь по белому списку.

3) Использование безопасных шаблонизаторов/фреймворков

Twig, Blade и др. автоматически экранируют вывод по умолчанию.Не отключать автоэкранирование.

4) Хранение $дляstoredXSS$

Никогда не полагайтесь на очистку при вводе; при выводе используйте контекстное кодирование.

5) Заголовки безопасности и cookie‑флаги

Устанавливать HttpOnly для сессионных cookie, чтобы JS не мог их читать.Secure для HTTPS.SameSite=strict/lax при необходимости.Content-Type: text/html; charset=UTF-8 и header${}^{\prime }X-Content-Type-Options:nosnif{f}^{\prime }$.X-Frame-Options / frame-ancestors CSP для защиты от clickjacking.

6) Использование библиотек для «очистки» HTML

Если нужно позволять пользователям вводить HTML $например,WYSIWYG$, применять whitelist‑фильтры и проверенные парсерные библиотеки $например,DOMPurifyнаклиенте;серверныеаналоги—HTMLPurifierдляPHP$.

Клиентская защита $дополнительная,нонезаменасерверу$

Content Security Policy $CSP$ — мощный механизм, см. ниже.Использование безопасных библиотек/фреймворков, которые корректно экранируют данные.CSP + HttpOnly куки + SameSite — снижают последствия успешной XSS, но не заменяют экранирование.

Роль и возможности Content Security Policy $CSP$

CSP позволяет ограничить, откуда можно загружать и выполнять ресурсы $скрипты,стили,изображенияит.д.$. Это снижает риск успешного XSS $например,предотвращаетзагрузкувнешнегоскриптаиливыполнениеinline‑скрипта$, но не заменяет экранирование.Примеры эффектов:
script-src 'self' — запрещает выполнение скриптов с чужих доменов.script-src 'self' 'nonce-...': позволяет разрешить конкретные inline‑скрипты с серверно‑сгенерированным nonce.script-src 'self' 'unsafe-inline' — ослабляет защиту $нерекомендуется$.CSP может блокировать эксплуатацию простых XSS $например,еслинастраницезапрещеныinline‑скриптыисторонниескрипты,тодажеесливнедрён<script>\dots </script>,онневыполнится$.Ограничения CSP:
CSP — это слой защиты «после», он работает на стороне клиента и может быть обойден, если политика слишком мягкая $например,разрешен{ы}^{\prime }unsafe-inlin{e}^{\prime }илисторонниедомены,которымзлоумышленникимеетдоступ$.CSP не спасёт, если злоумышленник сумеет внедрить допустимый контент $например,<imgonerror="...">приразрешённыхinlineсобытияхилиесливполитикеразрешеныданные:URIит.п.$.Нельзя полагаться только на CSP — всегда делать контекстное экранирование.

Примеры заголовков CSP

Жёсткая политика $можеттребоватьрефакторингаприложения$:
Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'none';Политика с nonce $дляконтролируемыхinlineскриптов$:
Генерируете случайный nonce на каждую страницу, добавляете в заголовок:
Content-Security-Policy: script-src 'self' 'nonce-random123';И на нужные теги …Рекомендация: применяйте CSP как дополнительный уровень защиты и используйте report-uri/report-to для мониторинга попыток нарушения.

Короткие безопасные примеры в PHP

Для вывода в HTML:
<?php echo htmlspecialchars($name, ENT_QUOTES | ENT_SUBSTITUTE, 'UTF-8'); ?>Для вставки в JS как строка:
var name = ;Для вставки в href:
link и дополнительно проверять схему: parse_url + whitelist http/https.При необходимости позволить часть HTML — прогнать через HTMLPurifier/DOMPurify $сервер/клиент$ с белым списком тегов и атрибутов.

Итог

Этот фрагмент уязвим к XSS; последствия — выполнение произвольного JS, кража данных и полномочий пользователя.Основная защита — контекстное выходное кодирование $encodeonoutput$ и валидация/белые списки на входе.CSP полезен как дополнительный барьер, но не заменяет корректного экранирования. Используйте CSP вместе с HttpOnly/ Secure куками, безопасными заголовками и шаблонизаторами с автоэкранированием.