Webman是PHP框架而非Python工具，安全加固需在PHP层、Swoole运行时、HTTP协议层和配置层协同完成：禁用硬编码敏感信息，强制参数化查询防SQL注入，输出前按上下文转义防XSS，手动实现CSRF Token校验，并严格配置Cookie属性。
webman 是 PHP 生态中基于 Swoole 的高性能框架，不是 Python 工具 —— 这一点必须先厘清。网上有混淆它和同名 Python 工具的误导信息，但你正在用的 webman 是纯 PHP 框架，所有安全加固都应在 PHP 语言层、Swoole 运行时、HTTP 协议层和配置层协同完成。
避免在 config/ 中硬编码敏感信息
直接把数据库密码、Redis 密钥写死在 config/database.php 或 config/redis.php 里，等于把钥匙挂在门把手上。一旦代码被泄露或服务器被入侵，攻击者能立刻连上你的核心服务。
- 改用
$_ENV或getenv()读取环境变量，例如：'password' => getenv('DB_PASSWORD') ?: '' - 确保
.env文件不在 Web 可访问路径下（如放在项目根目录外，或通过 Web 服务器规则禁止访问.env） - 部署时用
phpdotenv加载，但别在生产环境启用Dotenv::createUnsafeImmutable()—— 它会绕过权限检查
强制使用参数化查询防 SQL 注入
webman 自带的 think-orm 或 illuminate/database 都支持预处理，但开发者仍可能手滑拼接 SQL。比如在 app/model/User.php 中写 "WHERE name = '" . $name . "'"，就等于给攻击者开了后门。
- 永远用
where()、when()等构建器方法，而不是字符串拼接 - 若必须原生 SQL，只用
DB::select($sql, $bindings)形式，$bindings必须是数组，不能是空或 null - 禁用
DB::statement()执行用户可控的 DDL（如DROP TABLE），这类操作应仅限运维脚本
输出前必须做上下文敏感转义
XSS 不只发生在 <script></script> 标签里。攻击者可以把恶意 payload 塞进 href、onerror、甚至 CSS url() 中。你在 app/controller/IndexController.php 里 echo 用户昵称时，如果没处理，就可能触发存储型 XSS。
Webman 2.2.0版本强化了 TCP/UDP 服务支持，优化路由组管理，并增强异步任务处理能力。结合协程与连接池技术，Webman 能轻松应对高并发场景，适用于网站、接口服务、即时通讯、物联网及游戏开发，兼具高性能、灵活扩展与稳定可靠，是多场景 PHP 服务开发的理想选择。
- HTML 内容用
htmlspecialchars($str, ENT_QUOTES, 'UTF-8')，不要只用htmlentities()（它不处理单引号） - JS 上下文用
json_encode($str, JSON_UNESCAPED_UNICODE | JSON_HEX_TAG)，再包裹在''或""中 - URL 参数必须用
urlencode()，不是rawurlencode()（后者编码 / 和 ?，破坏路由）
启用并校验 CSRF Token（尤其表单和 AJAX）
webman 默认不内置 CSRF 中间件，但它的中间件机制完全支持手动实现。很多项目跳过这步，结果登录态被钓鱼页面悄悄复用，执行转账、删库等操作。
- 在表单中插入
- 自定义中间件检查
POST/PUT/DELETE请求的_token是否匹配session('csrf_token') - AJAX 请求需在请求头加
X-XSRF-TOKEN: {{ csrf_token() }}，并在中间件中读取验证 - 注意：CSRF Token 必须随 session 绑定，不能存在 Redis 共享缓存中供多实例复用（除非你做了分布式 session 同步）
关键点在于：安全不是加个中间件就完事。比如 StaticFile 中间件能防部分路径遍历，但它对 /.git/config 这类请求无感；session 配置里的 http_only 和 secure 必须为 true，否则 Cookie 可被 JS 读取或明文传输。这些细节不手动核对，很容易漏掉。
