AI建站后如何做安全加固，防止XSS和SQL注入？

学完这篇，你能按一套可执行的检查清单，把 AI 生成的网站从“能跑”加固到能挡住常见 XSS 和 SQL 注入。

第一步：盘点 AI 生成的代码，找出危险写法

这一步要确认哪些文件直接拼接 SQL、哪些地方把用户输入塞进 HTML，做完你会得到一份待修清单。在项目根目录执行：

grep -rnE "(query|exec|execute)\(.*(\$|\\+).*" --include="*.php" --include="*.js" .
grep -rnE "innerHTML|document\.write|eval\(|v-html|dangerouslySetInnerHTML" --include="*.js" --include="*.vue" --include="*.jsx" .
composer audit
npm audit --production

AI 建站常把 $_GET['id'] 直接拼进 SELECT，或把评论用 innerHTML 输出。把命中位置记下来。

注意：不要在生产库上直接扫，先复制一份 staging 环境和数据库。

第二步：用参数化查询堵住 SQL 注入

这一步要把所有 SQL 改成预处理语句，并给数据库最小权限，做完注入 payload 会变成普通字符串。PHP 8.2 + PDO 写法：

$pdo = new PDO($dsn, $user, $pass, [
  PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION,
  PDO::ATTR_EMULATE_PREPARES => false,
  PDO::MYSQL_ATTR_MULTI_STATEMENTS => false,
]);
$stmt = $pdo->prepare('SELECT * FROM users WHERE email = :email');
$stmt->execute([':email' => $email]);

Node.js 20 + mysql2 用 db.query('SELECT * FROM users WHERE email = ?', [email])。MySQL 8.0 里建专用账号：

CREATE USER 'web_rw'@'10.0.0.%' IDENTIFIED BY '强密码';
GRANT SELECT,INSERT,UPDATE,DELETE ON appdb.* TO 'web_rw'@'10.0.0.%';

不要给 FILE、SUPER、DROP 权限。

注意：表名、字段名、ORDER BY 方向不能参数化，必须用白名单数组映射，例如 $allowed = ['name','created_at']。

第三步：按输出场景做 XSS 编码

这一步要保证用户输入在进入 HTML、属性、JS 前被正确编码，做完脚本标签会显示成文本而不是执行。PHP 输出到 HTML 时用：

echo htmlspecialchars($str, ENT_QUOTES | ENT_SUBSTITUTE, 'UTF-8');

前端优先用 element.textContent = str，不要用 innerHTML。React 默认转义，但 dangerouslySetInnerHTML 必须配合 DOMPurify 3.x：

const clean = DOMPurify.sanitize(dirty, { ALLOWED_TAGS: ['b','i','p','a'] });

注意：编码要在输出时做，不要写入数据库前就转义，否则数据会变成 <，后续接口和搜索都会出错。

第四步：加安全响应头和 CSP

这一步让浏览器主动拦截可疑脚本和内嵌框架，做完 XSS 成功率和点击劫持风险会明显下降。Nginx 1.24 的 server 块加入：

add_header Content-Security-Policy "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; object-src 'none'; base-uri 'self'; frame-ancestors 'none'" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "DENY" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

执行 nginx -t && systemctl reload nginx。

注意：CSP 先改成 Content-Security-Policy-Report-Only 跑 1 到 2 天，确认没有误杀再换成正式头；内联 <script> 要外移到 .js 文件。

第五步：用 WAF 和限流挡自动化攻击

这一步在代码修复之外再加一层拦截，做完批量注入和暴力尝试会被直接封掉。Cloudflare 后台路径：登录 dash.cloudflare.com → 选择域名 → Security → WAF → Managed Rules → 将 Cloudflare Managed Ruleset 设为 On。再进 Security → WAF → Rate limiting rules，新建规则：路径 /login，阈值 5 次/分钟，动作 Block。Nginx 也可加：

limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;
location = /login { limit_req zone=login burst=3 nodelay; }

注意：WAF 不能替代参数化查询；新规则先开 Log 模式观察误杀。

第六步：收尾依赖、错误回显和会话安全

这一步把泄露堆栈和弱 Cookie 的坑补上，做完攻击者拿不到数据库结构。php.ini 设置：

display_errors = Off
log_errors = On
error_log = /var/log/php_errors.log
session.cookie_httponly = 1
session.cookie_secure = 1
session.cookie_samesite = Lax

并执行 composer audit、npm audit fix 升级已知漏洞依赖。

注意：数据库连接不要用 root；错误页不要输出 SQL 语句和堆栈。

第七步：用扫描器验证加固效果

这一步用工具对 staging 复测，做完你能看到哪些高危项还没修。OWASP ZAP 2.14.0 基线扫描：

docker run -t ghcr.io/zaproxy/zaproxy:stable zap-baseline.py \
  -t https://staging.example.com -r zap-report.html

只对自己拥有授权的 staging 用 sqlmap 验证：

sqlmap -u "https://staging.example.com/product?id=1" --batch --level=2 --risk=2

报告里的 High 和 SQL Injection、Cross Site Scripting 优先修。

注意：未授权扫描他人站点违法。

小结

• AI 生成的代码要人工审计 SQL 拼接和 innerHTML。
• SQL 注入靠 PDO/预编译参数化 + 数据库最小权限。
• XSS 靠输出编码、textContent、DOMPurify 和 CSP。
• Nginx 安全头、WAF、限流是第二道防线。
• 关闭错误回显，Cookie 加 HttpOnly、Secure、SameSite。
• 每次上线前用 ZAP 对 staging 复测。