webman中db::query()拼接字符串存在sql注入风险，必须改用query builder或参数化查询；输出用户数据需html转义防xss；cookie须设httponly和samesite；orm的whereraw()等方法也需参数化处理。
Webman里Db::query()拼字符串就是裸奔
只要看到Db::query()后面跟着双引号或单引号里拼变量，比如"SELECT * FROM user WHERE id = $id"，立刻停手——这不是写法问题，是生产环境直接开后门。Webman 的 Db::query() 不做任何拦截，传什么执行什么，攻击者填id=1 OR 1=1 --就能拖全表。
必须改用两种安全路径之一：
-
Db::table('user')->where('id', $id)->first()：Query Builder 自动参数绑定，变量不进 SQL 字符串 -
Db::query("SELECT * FROM user WHERE name = ?", [$name])：原生 SQL 必须带参数数组，问号占位符和数组顺序严格对应 - 禁用
Db::raw()塞用户输入，它只该用于Db::raw('NOW()')这类固定表达式 -
ORDER BY、LIMIT等无法参数化的地方，用白名单校验或强转：in_array($sort, ['id', 'name']) ? $sort : 'id'，intval($offset)
输出没转义，XSS就藏在echo里
Webman 视图层（无论原生 PHP 还是 ThinkTemplate）默认不做 HTML 转义。写<div>
<?php echo $request->get('comment'); ?></div>，用户提交<script>fetch('/api/steal?cookie='+document.cookie)</script>，浏览器真会执行。
所有用户数据输出到 HTML 页面前，必须上下文敏感处理：
- 普通文本输出：统一用
htmlspecialchars($str, ENT_QUOTES, 'UTF-8') - 插入
href或src属性：先过滤协议，再urlencode()，不能只靠htmlspecialchars - 富文本场景（如编辑器内容）：必须用白名单过滤器（如
HTMLPurifier），只放行<p></p>、<strong></strong>等安全标签 - 模板引擎若支持自动转义（如 Twig 的
{{ comment|e }}），确认已启用且未被全局关闭
Cookie缺HttpOnly/SameSite=Strict，XSS就能盗会话
Webman 默认 session cookie 不带关键安全属性。一旦页面存在 XSS 漏洞，攻击者执行document.cookie就能拿到 session_id，直接冒充用户发起请求。
Webman 2.2.0版本强化了 TCP/UDP 服务支持，优化路由组管理，并增强异步任务处理能力。结合协程与连接池技术，Webman 能轻松应对高并发场景，适用于网站、接口服务、即时通讯、物联网及游戏开发，兼具高性能、灵活扩展与稳定可靠，是多场景 PHP 服务开发的理想选择。
必须显式补全配置：
- 修改
config/session.php，加这两项：'cookie_httponly' => true、'cookie_samesite' => 'Strict'（或'Lax'） - 手动 setcookie 时，三项缺一不可：
setcookie('token', $val, [..., 'httponly' => true, 'samesite' => 'Lax', 'secure' => true]) -
secure属性只在 HTTPS 下生效，开发环境常被忽略，上线前务必检查 Nginx/Apache 是否强制 HTTPS 且响应头含Strict-Transport-Security
ORM模型不是自动免疫，whereRaw()是高危缺口
ThinkPHP 风格的 Model（继承\think\Model）在where()、find()里用变量是安全的，但whereRaw()、whereExists()这些“原始条件”方法接受字符串，底层不自动绑定参数。
例如$model->whereRaw("email = '{$_GET['email']}'")->find()，和拼接 SQL 无异。正确写法只有两种：
- 改用参数化形式：
$model->whereRaw("email = ?", [$email]) - 彻底避免
whereRaw()，拆成多个where()链式调用 - 模型类里别写
"WHERE name = '" . $name . "'"这种手拼 SQL，哪怕在app/model/User.php里也不行
最危险的不是主查询，而是日志记录、调试输出、缓存键生成这些辅助逻辑里悄悄拼了用户数据——它们不会报错，但可能成为二次注入入口。
