在PHP动态网站里，XSS攻击经常出现在开发者直接把用户提交的数据拼接到HTML输出的时候。攻击者可以通过表单、URL参数或API请求注入恶意脚本，一旦这些内容被浏览器当作HTML解析，就可能窃取Cookie、伪造请求或篡改页面内容。由于PHP大量使用echo、print等输出语句，如果缺少统一的转义策略，一个看似不起眼的回显点就会变成漏洞入口。下面从PHP最常见的数据流向拆解防护方案。
一、先分清XSS类型，才能定位PHP中的输出点
XSS攻击通常分为反射型、存储型和DOM型三类。前两类与PHP后端直接相关：反射型XSS由URL参数触发，服务器将参数原样回显到页面中；存储型XSS则是攻击者把恶意脚本提交到数据库，其他用户访问时脚本被读取并执行。DOM型XSS主要发生在浏览器端JavaScript处理环节，PHP虽然不直接负责DOM操作，但通过接口返回的数据也可能成为DOM型XSS的数据源。
判断一个PHP站点是否存在XSS风险，最直接的方法是检查所有输出函数。比如下面的代码读取$_GET中的name参数并直接输出：
<?php $name = $_GET['name']; echo "欢迎，".$name; ?>
如果访问index.php?name=<script>alert(1)</script>，浏览器会将<script>标签解析为可执行脚本。类似的输出位置还包括HTML属性、<textarea>内容、style属性以及内嵌JavaScript片段。不同上下文中，危险字符的转义方式并不相同，所以不能用一个简单的字符串替换覆盖所有场景。
PHP中常见的输出函数除了echo和print，还包括printf、sprintf、var_dump、print_r以及模板引擎的变量输出。只要这些函数把未经处理的数据写入HTML文档，攻击者就有机会构造闭合标签、属性或脚本片段的payload。因此，防护的第一步是明确哪些变量来自用户输入，并为它们建立统一的输出转义入口。
二、输出编码：htmlspecialchars与htmlentities的正确使用
PHP内置的htmlspecialchars函数可以将特殊字符转换为HTML实体，默认会处理&、<、>、"四个符号。但默认情况下它不会转换单引号，如果输出位于单引号包裹的HTML属性中，攻击者可以闭合属性并注入事件处理器。因此在实际使用中必须显式传入ENT_QUOTES标志，同时指定UTF-8字符集，避免因编码不一致导致绕过。
建议为项目封装一个全局转义函数，统一处理文本节点的输出：
<?php
function e($str) {
return htmlspecialchars($str, ENT_QUOTES, 'UTF-8');
}
$userName = $_GET['name'];
echo "欢迎，".e($userName);
?>
这样所有输出到HTML正文的变量都经过转义，<script>会变成<script>，浏览器只显示文本而不会执行脚本。需要注意的是，htmlspecialchars只适用于HTML文本和属性值上下文。如果把转义后的数据放进<script>标签内部或JavaScript事件处理器中，实体不会被JavaScript解析器还原，但攻击者仍然可以利用JavaScript的字符串拼接方式绕过。对于JavaScript上下文，应当使用json_encode配合JSON_HEX_TAG等参数，或者避免直接输出动态内容到脚本中。
htmlentities函数会转换所有可转换的HTML实体，范围比htmlspecialchars更大，但在多数场景下并不必要，而且会消耗更多资源。关键是不要重复编码：如果一个变量已经经过转义，再次调用htmlspecialchars会把<变成&lt;，导致页面显示异常。可以通过约定函数命名或使用模板引擎自动转义来避免重复调用。
三、输入过滤和富文本清洗不能混为一谈
很多PHP教程会建议在接收用户输入时过滤掉<script>等危险标签，这确实可以降低风险，但输入过滤不能替代输出编码。攻击者可以使用大小写混写、编码混淆、标签嵌套或插入空字节等方式绕过简单的字符串替换。输入过滤的主要目的是保证数据格式符合业务预期，例如邮箱必须是邮箱格式、手机号必须是数字，而不是把数据改造成安全的HTML。
对于格式明确的字段，可以使用PHP的filter_var函数进行白名单校验：
<?php
$email = $_POST['email'];
if (!filter_var($email, FILTER_VALIDATE_EMAIL)) {
exit('邮箱格式不正确');
}
$age = $_POST['age'];
if (!filter_var($age, FILTER_VALIDATE_INT)) {
exit('年龄必须是整数');
}
?>
这段代码只接受合法的邮箱和整数，不符合格式的输入会被直接拒绝。对于URL、IP地址、布尔值等类型，filter_var也提供了对应的过滤器。白名单校验的优势在于它只允许已知安全的数据通过，避免黑名单遗漏。但业务中有时需要用户提交带格式的富文本，比如文章评论支持加粗、列表等HTML标签，这种情况下白名单校验会误伤正常内容，需要引入专门的HTML清洗库。
HTMLPurifier是PHP中广泛使用的富文本过滤库，它根据一套可配置的白名单规则解析HTML，移除所有不在白名单中的标签和属性，同时保留安全的排版效果。基本用法如下：
<?php require_once 'HTMLPurifier.auto.php'; $config = HTMLPurifier_Config::createDefault(); $purifier = new HTMLPurifier($config); $dirtyHtml = $_POST['content']; $cleanHtml = $purifier->purify($dirtyHtml); echo $cleanHtml; ?>
经过HTMLPurifier处理后，<script>、onclick等危险内容会被剥离，而<strong>、<p>等安全标签可以保留。需要注意的是，HTMLPurifier的输出已经是安全的HTML，不应再对它执行htmlspecialchars，否则会显示实体源码。富文本清洗与普通输出转义是两条不同的处理路径，应当根据字段内容类型分别选择。
四、HttpOnly Cookie与CSP响应头构建第二道防线
即使输出编码做得再严格，也有可能出现遗漏的角落，因此纵深防御非常重要。HttpOnly是Cookie的一个属性，设置后浏览器禁止JavaScript通过document.cookie读取该Cookie。攻击者即使成功注入脚本，也无法直接窃取会话ID，这能显著降低会话劫持的风险。PHP中可以在setcookie函数中增加httponly参数：
<?php
setcookie('session_id', $sessionId, [
'httponly' => true,
'secure' => true,
'samesite' => 'Strict'
]);
?>
对于使用session_start管理的会话，可以在php.ini中设置session.cookie_httponly = 1，也可以在运行时通过ini_set或session_set_cookie_params动态配置。这样即使脚本注入成功，攻击者也无法通过document.cookie拿到会话标识，只能尝试其他攻击方式。
内容安全策略（CSP）是另一层有力的防护。通过设置响应头Content-Security-Policy，可以限制浏览器只执行来自指定来源的脚本。例如只允许同源脚本执行，可以使用以下PHP代码：
<?php
header("Content-Security-Policy: default-src 'self'; script-src 'self'");
?>
这个响应头告诉浏览器只信任同源资源，任何内联脚本或外部域脚本都会被阻止，即使攻击者注入了<script>标签，浏览器也不会执行。对于需要内联脚本的旧项目，可以使用'unsafe-inline'作为临时过渡，但会削弱防护效果。更好的做法是提取外部脚本文件，并配合nonce或哈希机制允许特定的内联脚本。CSP可以配置为Content-Security-Policy-Report-Only模式先收集违规报告，确认不影响正常业务后再正式启用。
综合来看，PHP动态网站防止XSS攻击没有单一银弹，需要把输出编码作为日常开发的基本功，用输入校验保证数据格式，用HttpOnly和CSP等机制提供兜底。无论使用原生PHP还是ThinkPHP、Laravel等框架，都应该清楚框架自带的转义函数在哪些场景失效，并在模板渲染、接口返回、富文本展示等不同输出点采取对应策略。只有覆盖从数据输入到浏览器渲染的完整链路，才能把XSS风险控制在可接受的范围内。