北京
AI编程助手几分钟就能生成可用的FastAPI端点，但它们在不同代码库中反复犯着同样的五种安全错误。BrassCoders团队说，不是因为FastAPI本身不安全——官方安全文档对参数化查询和身份验证模式讲得很清楚。
问题出在训练数据上。AI从数以百万计的教程示例和StackOverflow答案中学习，其中很多为了简洁而采用了不安全的写法。AI预测接下来该写什么，而教程里接下来常常就是直接往SQL查询里拼接变量的代码。
BrassCoders能用其开源扫描器一次性检测出下面这五种模式，工具集包括Bandit、Yelp的detect-secrets，以及三个针对AI引入反模式的定制检测器。
AI编程助手本质上是模式补全引擎，它们见得最多的模式不一定是正确的模式。Python Web API的训练数据偏向教程和快速上手指南——代码追求的是可读性，而不是安全性。一条StackOverflow答案用f-string拼接SQL查询展示FastAPI路由写法，因为清晰易懂而获得高赞。同样的代码被AI助手大规模复制，SQL注入漏洞就此上线。
这是结构性问题。靠提示工程只能勉强改善判断。更可靠的方案是：在AI代码生成后运行扫描器，标记AI助手反复出错的具体模式。
第一种模式是用f-string拼接SQL查询导致注入风险。BrassCoders用Bandit的B608规则检测这种写法，一旦发现SQL语句中直接插入了用户可控的值就会报警。AI生成的典型代码看起来没问题：user_id被FastAPI标记为int类型，确实能挡住最明显的字符串注入载荷——但挡不住全部。更要命的是，这种写法教会AI和读代码的开发者f-string拼SQL没问题。同样的写法复制粘贴到字符串类型字段上，就成了教科书级别的SQL注入。OWASP API安全Top 10中，注入攻击被列为API8:2023，横跨数据库查询、Shell命令和模板引擎。正确的做法是参数化查询，BrassCoders能抓到f-string版本，参数化版本则不会触发检测。
第二种模式是配置中硬编码凭据。BrassCoders检测硬编码的密钥、密码和令牌，这些凭据直接写在源代码里而非环境变量或密钥管理服务中。
第三种模式涉及异常处理暴露内部信息。AI常生成直接向客户端返回原始异常的端点，这会泄露数据库结构、文件路径和内部逻辑。BrassCoders标记返回未经处理的异常对象或将堆栈跟踪返回给客户端的模式。
第四种是缺少速率限制。AI生成的端点通常不带任何限速机制，BrassCoders检测缺少速率限制中间件的端点定义，这类端点天然面临暴力破解和资源耗尽的风险。
第五种是过度宽松的CORS配置。AI倾向于生成允许所有来源的CORS设置，BrassCoders检测allow_origins=["*"]这类配置，并标记同时允许所有来源又允许携带凭据的危险组合。
这五种模式的共同点在于：教程里为了展示功能而写的简略代码，被AI当成生产级代码的标准写法。解决思路不是在每次提问时叠加安全提示，而是在代码落地前加一层自动检查。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
