由 dawei SQL注入是PHP应用中最经典的安全威胁，根源在于将用户输入直接拼接到SQL语句中。例如使用mysqli_query(\”SELECT FROM users WHERE id = \” . $_GET[‘id’])，攻击者传入1 OR 1=1–即可绕过条件，读取全部数据。
防御核心是“分离数据与逻辑”。优先采用预处理语句（Prepared Statements），将SQL结构与参数彻底解耦。使用PDO时，应绑定参数：$stmt = $pdo->prepare(\”SELECT FROM users WHERE email = ?\”); $stmt->execute([$_POST[’email’]]); 这样即使输入含单引号或分号，数据库也仅视其为字符串值。
AI设计，仅供参考
对于动态表名、字段名等无法参数化的场景，必须白名单校验。例如切换排序字段时，仅允许[‘name’, ‘created_at’, ‘status’]中的值，通过in_array($sort, [‘name’,’created_at’])严格判断，拒绝一切非常规输入。
输出到HTML前，务必过滤XSS风险。不要依赖前端验证或JS过滤，PHP后端须调用htmlspecialchars($user_input, ENT_QUOTES, ‘UTF-8’)转义特殊字符。若需保留部分HTML格式，应使用HTMLPurifier等成熟库，而非正则简单替换。
文件操作同样高危。避免将$_GET[‘file’]直接用于include或file_get_contents。若需动态加载资源，应限定目录范围（如限定在./templates/下），并使用basename()提取文件名，再结合白名单校验扩展名，杜绝路径遍历与远程文件包含。
密码处理严禁明文存储或弱哈希。始终使用password_hash($password, PASSWORD_ARGON2ID)生成密钥，并用password_verify()验证。避免自建加盐逻辑，PHP原生函数已集成安全随机盐与适应性迭代。
启用错误报告的生产环境要关闭display_errors，改设log_errors = On，防止敏感路径、数据库结构等信息泄露。同时配置open_basedir限制脚本可访问的文件系统范围，降低任意文件读取影响。
安全不是功能补丁，而是开发习惯。每次接收外部输入（GET、POST、COOKIE、文件上传、HTTP头）都默认不可信；每次拼接命令、查询、HTML、文件路径前，先问“是否经验证？是否被转义？是否在可控范围内？”持续代码审计与OWASP Top 10对照，才能筑牢防线。