webman默认不提供sql注入和xss防护，需开发者显式实现：sql必须用query builder或参数化查询，输出需htmlspecialchars转义，cookie须设httponly/samesite/secure属性。
Webman 默认不内置 SQL 注入或 XSS 的自动防护，所有防护必须由开发者显式实现——它不替你过滤输入、不帮你转义输出、也不强制使用参数化查询。依赖框架“默认安全”会直接导致线上漏洞。
Webman 中 Db::query() 拼接字符串的危险行为
很多人在 Webman 里写 SQL 时仍习惯字符串拼接，比如：
$id = $request->get('id');
$result = Db::query("SELECT * FROM user WHERE id = $id"); // ❌ 危险！
这种写法等同于裸奔：攻击者传 id=1 OR 1=1 就能拖库。Webman 的 Db 类本身不拦截或警告这类写法，它只负责执行。
- 必须改用
Db::table()->where()->get()等 Query Builder 接口，它们底层走参数化绑定 - 若必须用原生 SQL，只能通过
Db::query($sql, $params)形式传参，例如：Db::query("SELECT * FROM user WHERE name = ?", [$name]) -
Db::raw()是高危函数，仅用于字段/函数表达式（如Db::raw('NOW()')），绝不能拼用户输入
Webman 响应中未转义用户输入导致 XSS
Webman 的视图渲染（如使用 ThinkTemplate 或原生 PHP echo）不做 HTML 转义。比如：
Webman 2.2.0
下载
Webman 2.2.0版本强化了 TCP/UDP 服务支持，优化路由组管理，并增强异步任务处理能力。结合协程与连接池技术，Webman 能轻松应对高并发场景，适用于网站、接口服务、即时通讯、物联网及游戏开发，兼具高性能、灵活扩展与稳定可靠，是多场景 PHP 服务开发的理想选择。
<div>
<?php echo $request->get('comment'); ?></div> // ❌ 可被注入 <script>alert(1)</script>
浏览器会真实执行这段 JS，尤其当 comment 来自数据库（存储型 XSS）或 URL（反射型 XSS）时风险极高。
- 前端输出前必须调用转义函数：
htmlspecialchars($str, ENT_QUOTES, 'UTF-8') - 若用 Twig 模板，用
{{ comment|e }}；若用 Blade 风格自定义模板，确保默认开启自动转义 - 富文本场景不能简单转义，需用白名单过滤器（如
HTMLPurifier），仅放行<p></p>、<strong></strong>等安全标签
Webman 中 Cookie 缺少 HttpOnly 和 SameSite 属性
Webman 默认设置 session cookie 时不带关键安全属性，攻击者可通过 XSS 获取 cookie 后发起 CSRF 或盗用会话。
- 手动配置 session：在
config/session.php中显式添加：'cookie_httponly' => true、'cookie_samesite' => 'Strict'（或Lax） - 自定义 Cookie 时务必补全：
setcookie('token', $val, [..., 'httponly' => true, 'samesite' => 'Lax', 'secure' => true]) -
secure属性在 HTTPS 环境下才生效，开发环境容易忽略，上线前必须检查
最易被忽略的是：Webman 的中间件执行顺序决定了防护是否生效。比如 XSS 输出转义必须放在响应生成之后、发送之前；而 SQL 参数化必须在查询构造阶段完成——任何“事后补救”都无效。
