PHP防SQL注入和XSS的核心是：数据库操作必须用参数化查询（PDO禁用模拟预处理、杜绝字符串拼接），模板输出须按HTML/JS/CSS/URL上下文分别转义，辅以CSP等HTTP安全头及输入校验、最小权限等纵深防御措施。
PHP框架里防SQL注入和XSS，核心就两条：数据库操作必须用参数化，模板输出必须做上下文适配转义。不靠经验猜，得靠机制卡死。
PDO参数化查询防SQL注入
预处理语句不是“用了就行”，关键在真实预处理生效、参数类型绑定到位、字符串拼接彻底禁绝。
- 数据库配置中强制关闭模拟预处理：
'ATTR_EMULATE_PREPARES' => false，否则PDO会把占位符替换成字符串再发给MySQL，等于白设 - 优先走框架封装的查询构造器，比如ThinkPHP的
where('id', input('id'))或Laravel的where('email', $email)，底层自动完成类型识别与绑定 - 写原生SQL时只接受问号
?或命名参数:name，且必须传数组或键值对，例如Db::query("SELECT * FROM user WHERE level > ? AND status = ?", [5, 1]) - 绝对禁止
"WHERE name = '" . $_GET['name'] . "'"这类拼接，哪怕加了(int)或filter_var()也不行——它们防不住联合查询、报错注入等绕过手法
输出环节按场景选转义方式防XSS
用户数据进页面不是“转一下就安全”，HTML、JS、CSS、URL上下文不同，转义规则完全不同，统一用htmlspecialchars()会漏防。
- 插入HTML文本（如评论、简介）：用
htmlspecialchars($str, ENT_QUOTES | ENT_HTML5, 'UTF-8')，三参数缺一不可 - 赋值给JavaScript变量：必须用
json_encode($str, JSON_UNESCAPED_UNICODE | JSON_HEX_TAG | JSON_HEX_AMP)包裹，不能直接echo进var x = "xxx" - 作为URL参数或href属性：用
urlencode()或框架的url()辅助函数，避免&、=被解析为分隔符 - 富文本内容（如编辑器输出）：禁用
htmlspecialchars，改用HTMLPurifier配置白名单，只放行p、strong、img等安全标签，过滤onerror、javascript:等危险属性
HTTP安全头补强防御纵深
服务端响应头是浏览器执行策略的第一道指令，能堵住很多绕过前端转义的XSS路径。
立即学习“PHP免费学习笔记（深入）”；
-
Content-Security-Policy：至少限制脚本只允许加载自身域名，如script-src 'self';，可进一步禁用内联脚本'unsafe-inline' -
X-Content-Type-Options: nosniff：防止MIME类型嗅探导致HTML被误解析为可执行脚本 -
X-Frame-Options: DENY或Content-Security-Policy: frame-ancestors 'none'：防点击劫持 -
Set-Cookie中加上HttpOnly和Secure标志，切断JS读取session cookie的通路
输入验证与运行环境加固
防御不止在代码层，配置和流程也得跟上。
- php.ini中关闭
display_errors = Off，开启log_errors = On，避免数据库结构、路径等敏感信息回显到页面 - 数据库账号遵循最小权限原则，应用账户不授予
DROP、CREATE、FILE等高危权限 - 所有表单提交启用CSRF Token校验，尤其修改类操作（删除、转账、权限变更），Token需绑定用户会话且一次性使用
- 对上传文件严格校验后缀、MIME类型、内容头，重命名存储，禁止Web目录直接访问上传目录
