Flask 应用安全开发与审计规范实战指南：从安全基线配置到漏洞规则扫描（基于 skills 仓库 Python Flask Security Spec）

Flask 应用安全开发与审计规范实战指南从安全基线配置到漏洞规则扫描基于 skills 仓库 Python Flask Security Spec【免费下载链接】skillsSkills Catalog for Codex项目地址: https://gitcode.com/GitHub_Trending/skills4/skills本篇指南以当前仓库skills中 python-flask-web-server-security.md 安全规格文档为主体完整解析其面向 Flask 3.1.x / Python 3.x 的安全规格Security Spec、生产环境安全基线、18 条带严重级别的安全规则与扫描启发式方法。该文档是 security-best-practices skill 的框架级参考文件用于指导 Codex 类 AI 智能体在生成 Flask 代码时默认安全、在编辑过程中被动发现漏洞、并在显式请求时输出结构化审计报告。读者学完后将能按 MUST/SHOULD/MAY 规范编写 secure-by-default 的 Flask 应用掌握从入口点、配置、会话、CSRF、XSS/SSTI 到文件处理、注入、SSRF 的完整审计清单并可直接套用本文的规则编号与修复模式。一、这份规格文档是什么定位、边界与三种操作模式该文档被设计为一份规范性安全规格normative security spec同时支撑两类任务Secure-by-default 代码生成面向新写 Flask 代码安全审查 / 漏洞挖掘面向存量 Flask 代码既包括编辑时被动发现问题notice issues while working也包括用户显式要求时的扫描仓库并输出发现scan the repo and report findings。其行文方式刻意采用MUST / SHOULD / MAY的 RFC 式规范语气并配套审计规则坏模式长什么样、如何检测、如何修复/缓解与仓库中同目录下的其他语言规格如 python-django-web-server-security.md、python-fastapi-web-server-security.md共同构成 skill 的references/知识库由 SKILL.md 中的工作流按language-framework-stack-security.md命名规则加载。0安全边界与防滥用约束MUST FOLLOW在任何模式下都必须遵守以下边界禁止请求、输出、记录或提交任何密钥API Key、密码、私钥、会话 Cookie、SECRET_KEY禁止通过关闭防护来修复安全问题例如关闭 CSRF、放宽 CORS、禁用转义、跳过认证检查审计时必须提供基于证据的发现给出文件路径、代码片段与配置值来支撑结论必须诚实地对待不确定性如果某类防护可能存在于基础设施层反向代理、WAF、CDN应报告为应用代码中不可见请在运行时/配置中核实。1Generation mode生成模式默认当被要求编写新 Flask 代码或修改现有代码时MUST遵守本规格中每一条 MUST 要求SHOULD遵守每一条 SHOULD 要求除非用户明确说明例外MUST优先使用 safe-by-default 的 API 和成熟库而非自己手写安全代码MUST避免引入新的风险汇点risk sinks包括由字符串渲染模板、shell 执行、动态导入、不安全的重定向、把用户文件当作 HTML 直接提供等。2Passive review mode被动审查模式编辑时始终开启即使在一个 Flask 仓库里工作且用户并未要求安全扫描MUST在接触/邻近的代码中注意到对本规格的违反SHOULD在问题出现时主动提及附上简要说明 安全修复方案。3Active audit mode主动审计模式显式扫描请求当用户要求 scan、audit、hunt for vulns 时MUST系统性地搜索代码库中违反本规格之处MUST按 §2.3 的结构化格式输出发现。推荐的审计顺序按检查纵深排列应用入口点 / 部署脚本 / Dockerfile / ProcfileFlask 配置与环境变量处理认证 会话 CookieCSRF 防护与状态变更路由模板渲染与 XSS/SSTI文件处理上传 下载与路径穿越注入类SQL、命令执行、不安全反序列化出站请求SSRF重定向处理开放重定向CORS 与安全响应头。二、核心定义与审计发现格式§22.1 不可信输入Untrusted input除非证明可信否则一律视为攻击者可控典型来源包括request.args、request.form、request.valuesrequest.get_json()、request.json、request.datarequest.headers、request.cookiesURL 路径参数如/user/id来自外部系统的任何数据Webhook、第三方 API、消息队列任何源于用户的持久化内容数据库行2.2 状态变更请求State-changing request当请求可以创建/更新/删除数据、改变认证/会话状态、触发副作用购买、发邮件、发 Webhook或发起特权操作时即视为状态变更请求——这类请求是 CSRF 防护的核心对象。2.3 审计发现的标准输出格式每个问题必须包含以下字段Rule ID规则编号SeverityCritical / High / Medium / LowLocation文件路径 函数/路由名 行号Evidence确切的代码/配置片段Impact可能发生什么、谁能利用Fix安全的修改优先最小 diffMitigation当无法立即修复时的纵深防御手段False positive notes不确定时需核实的内容。这一格式与 SKILL.md 的报告章节 的要求一致报告需有执行摘要、按严重程度划分章节、所有发现用数字 ID 编号、关键发现附带一句话影响说明、引用的代码必须包含行号。三、安全基线最小生产配置MUST in production3.1 应用初始化模式SHOULDSHOULD 使用**应用工厂app factory**与基于环境的配置避免生产配置被硬编码从环境变量 / 密钥仓库加载配置生产环境中若关键设置缺失应fail closed宁可拒绝启动也不要裸奔。3.2 基线配置目标SECRET_KEY已设置且未提交到仓库SESSION_COOKIE_SECURETrue仅当 HTTPS 时重要提示——只有当 TLS 已配置的生产环境中才设置Secure本地开发走 HTTP 时不要设置该属性。应当基于应用是否处于生产模式来条件性设置并提供一个类似SESSION_COOKIE_SECURE的可开关配置以便在 HTTP 下测试时禁用安全 CookieSESSION_COOKIE_HTTPONLYTrueSESSION_COOKIE_SAMESITELax若兼容亦可Strict生产环境设置TRUSTED_HOSTS安全响应头CSP 等在应用内或边缘edge设置。四、规则全解生成与审计双用途§4共 18 条每条规则都包含Required要求、Insecure patterns不安全模式、Detection hints检测线索、Fix修复、Notes备注。下面按主题分组完整展开。4.1 部署与运行环境FLASK-DEPLOY-001生产环境不得使用 Flask 开发服务器Severity: High若用于生产RequiredMUST NOT 将内置开发服务器部署为生产服务器MUST 在成熟的生产级 WSGI 服务器或托管平台上运行例如 gunicorn。不安全模式生产入口点中出现app.run(...)部署文档/脚本用flask run跑生产。检测线索搜索app.run(、flask run、--debug、FLASK_DEBUG、FLASK_ENVdevelopment检查 Docker CMD/ENTRYPOINT、Procfile、systemd 单元、shell 脚本。修复改用生产 WSGI 服务器Flask 仍作为应用对象开发服务器仅用于本地开发。备注开发模式或本地测试中使用这些属于允许范围只有明确用作生产入口点时才标记。FLASK-DEPLOY-002生产环境必须禁用调试模式Severity: CriticalRequiredMUST NOT 在生产启用 debugMUST 将暴露的交互式调试器视为等同于远程代码执行。不安全模式app.run(debugTrue)生产中使用flask run --debug生产环境通过 env/config 设DEBUGTrue。检测线索查找debugTrue、FLASK_DEBUG1、DEBUG True、app.debug True非测试上下文中的TRAP_HTTP_EXCEPTIONS/ 调试器设置。修复debug 仅在本地开发/测试开启优先使用基于环境的开关和安全默认值。备注开发/本地测试中使用允许仅当用作生产入口点时才标记。4.2 配置与密钥FLASK-CONFIG-001SECRET_KEY 必须强、保密且安全轮换Severity: High生产缺少且使用会话/签名时为 CriticalRequired生产 MUST 设置强随机SECRET_KEYMUST 将其排除在源码控制与日志之外MAY 定期轮换MAY 使用SECRET_KEY_FALLBACKS在轮换期不使现有会话立即失效窗口期结束后移除旧密钥。这对小型应用通常并非必需但对大型应用是好实践因其可能使部署复杂化建议先提出该方案而非默认直接实现。不安全模式生产缺少SECRET_KEY仓库中硬编码SECRET_KEY包括测试密钥误用于生产日志或打印SECRET_KEY。检测线索搜索SECRET_KEY 、app.secret_key 、SECRET_KEY_FALLBACKS 检查是否将.env提交进仓库检查配置模块中的常量。修复从密钥管理器或环境变量加载建立轮换流程——设置新SECRET_KEY→ 旧密钥暂时保留在SECRET_KEY_FALLBACKS→ 安全窗口结束后移除旧密钥。备注若应用使用 Flask 会话默认基于 CookieSECRET_KEY直接关乎安全。4.3 会话与 CookieFLASK-SESS-001生产环境会话 Cookie 必须使用安全属性Severity: MediumRequired生产 HTTPSMUST 设置SESSION_COOKIE_SECURETrueCookie 仅走 HTTPS。注意仅在生产且配置了 TLS 时设置Secure本地 HTTP 开发环境不要设置应基于生产模式条件化并提供类似SESSION_COOKIE_SECURE的开关便于 HTTP 测试。MUST 确保SESSION_COOKIE_HTTPONLYTrue防止 JS 读取SHOULD 设置SESSION_COOKIE_SAMESITELax推荐或与 UX 兼容时的StrictSHOULD 保持SESSION_COOKIE_DOMAINNone除非确实需要跨子域 Cookie若需要 iframe 第三方嵌入MAY 考虑SESSION_COOKIE_PARTITIONEDTrue要求 HTTPS。不安全模式生产环境SESSION_COOKIE_SECUREFalseSESSION_COOKIE_HTTPONLYFalse基于 Cookie 认证的状态变更端点使用SESSION_COOKIE_SAMESITENoneCSRF 风险更高。检测线索检查app.config.update(...)块与配置类非会话 Cookie 的set_cookie(..., secure..., httponly..., samesite...)用法同样要检查。修复在生产配置中显式设置这些配置值。备注SameSite 是纵深防御不能替代 CSRF Token。FLASK-SESS-002会话必须有界并抵抗固定/重放Severity: MediumRequiredSHOULD 设置与应用匹配的有界会话生命周期仅在确实需要持久会话时设置session.permanent True并为PERMANENT_SESSION_LIFETIME设定合理值SHOULD 在登录与权限变更时清空会话降低会话固定fixation风险MUST NOT 在默认 Flask 会话 Cookie 中存储敏感机密——默认会话是签名而非加密的。不安全模式特权会话生命周期过长或无限制登录时不清理会话在默认 Cookie 会话中直接把密码、访问令牌、PII 存入session[...]。检测线索搜索PERMANENT_SESSION_LIFETIME、session.permanent、session[...] 判断是否使用服务端会话存储若无则假定为默认 Cookie 会话。修复设置合理生命周期登录时清空/轮换会话敏感数据存服务端会话 Cookie 只存标识符。4.4 CSRF 防护FLASK-CSRF-001基于 Cookie 认证的状态变更请求必须受 CSRF 防护Severity: High重要说明若认证不依赖 Cookie例如使用 Authorization 头或其他传递的 Token则不存在 CSRF 风险。RequiredMUST 保护所有依赖 Cookie 认证的状态变更端点POST/PUT/PATCH/DELETEMAY 使用经过充分测试的 CSRF 库/集成表单框架或中间件而非自研MAY 附加 Origin/Referer 检查、SameSite Cookie、Fetch Metadata 头、AJAX/API 自定义头等防御但Token 仍是 Cookie 认证应用的主要防御。若 Token 不可行或应用很小MUST 至少要求设置自定义头并将会话 Cookie 设为SESSION_COOKIE_SAMESITElax——这是除表单 Token 外最强、且可能更易实现的方法。不安全模式基于 Cookie 认证的状态变更端点无 CSRF 防护用 GET 执行状态变更放大 CSRF 风险。检测线索枚举非 GET 方法的路由并识别认证机制查找 CSRF 集成如 Flask-WTF、全局 CSRF 中间件缺失即视为可疑JSON API 端点也要检查不能只看 HTML 表单。修复为所有状态变更请求添加 CSRF 防护若应用是纯 API 且用 Authorization 头Bearer Token而非 Cookie则记录该选择并确保 Cookie 不用于认证——不用 Cookie 认证即无 CSRF 风险。备注XSS 可以击穿 CSRF 防护CSRF 防御不能替代 XSS 防御。4.5 XSS 与模板安全FLASK-XSS-001防止模板与 HTML 生成中的反射型/存储型 XSSSeverity: HighRequiredMUST 依赖 Jinja 自动转义渲染 HTML 模板MUST NOT 把不可信内容标记为安全——避免对用户数据使用Markup(...)、避免 Jinja|safe用于用户可控内容MUST 为包含 Jinja 表达式的 HTML 属性加引号value{{ x }}而非value{{ x }}MUST NOT 将用户上传的 HTML 作为活动 HTML 提供应作为下载Content-Disposition: attachment或转换为安全格式注仅当可上传 html/js/css 等文档内容时相关若纯图片文件则无此顾虑SHOULD 部署 CSP 以缓解 XSS 类攻击包括href中的javascript:。不安全模式Markup(request.args.get(...))模板过滤器{{ user_html|safe }}模板中未加引号的属性直接将用户上传内容以text/html或内联渲染方式提供。检测线索搜索Markup(并追溯数据来源搜索模板中的|safe、|tojson误用与未加引号属性审查可能以as_attachmentTrue之外方式返回用户上传文件的文件服务路由。修复移除不安全标记仅在确实必要时用可信 HTML 消毒器清洗始终给属性加引号添加 CSP 并减少内联脚本。FLASK-SSTI-001绝不渲染不可信模板服务端模板注入Severity: CriticalRequiredMUST NOT 渲染包含用户可控模板语法的模板MUST 将render_template_string与Environment.from_string(...).render(...)视为危险操作当模板字符串受不可信输入影响时MUST NOT 对用户可控字符串使用.format()。若确实必须渲染不可信模板视为特殊高风险设计MUST 使用沙箱化模板方案并限制能力MUST 保持 Jinja 更新并假设沙箱存在逃逸可能进一步隔离。不安全模式render_template_string(request.args[tmpl], ...)将用户模板存数据库并用正常 Jinja 环境渲染request.args[tmpl].format(...)。检测线索greprender_template_string、from_string、.render(并关注动态字符串追溯模板字符串来源数据库、请求、上传、管理后台。修复替换为不执行代码的安全模板方案如string.Template、str.replace若必须用户自定义模板用沙箱 严格白名单 重度隔离。4.6 安全响应头FLASK-HEADERS-001设置必备安全响应头应用内或边缘Severity: MediumRequired典型 Web 应用SHOULD 设置——CSPContent-Security-Policy、X-Content-Type-Options: nosniff、点击劫持防护X-Frame-Options: SAMEORIGIN和/或 CSPframe-ancestors若用户希望自己的站点被 iframe 嵌入需与其协作安全放行SHOULD 视应用情况考虑更多加固头Referrer-Policy、Permissions-PolicyMUST 确保 Cookie 具备安全属性见 FLASK-SESS-001。注意安全响应头可能由代理或云厂商设置需检查是否存在相关证据。不安全模式应用与边缘均无任何安全头显示不可信内容的应用缺少 CSP。检测线索搜索after_request钩子、Flask-Talisman 用法、反向代理配置若应用代码中不可见标记为请在边缘核实。修复在中间件 /after_request或反向代理 / CDN 集中设置保持 CSP 务实可兼容尽量避免unsafe-inline。4.7 资源限制与主机验证FLASK-LIMITS-001请求大小与表单解析限制必须恰当设置Severity: Low存在文件上传/大请求体时为 MediumRequiredSHOULD 设置并说明依据——MAX_CONTENT_LENGTH全局最大请求字节数、MAX_FORM_MEMORY_SIZEmultipart 中每个非文件表单字段的最大值、MAX_FORM_PARTSmultipart 字段最大数量MUST 尽可能在反向代理 / WSGI / 平台层追加限制。不安全模式处理上传或用户内容时请求体无限制接受任意大的 multipart 表单或过多字段。检测线索检查 Flask 配置中这些键检查上传路由与接受大 JSON 的 API。修复设置保守默认值仅按路由需要覆盖大上传走专用上传机制。FLASK-HOST-001生产环境必须校验 Host 头Severity: Low取决于应用对外部 URL 的使用RequiredMUST 在生产设置TRUSTED_HOSTS限制可接受的 Host 值MUST NOT 依赖SERVER_NAME作为主机限制机制。不安全模式生产未设置TRUSTED_HOSTS生成外部 URL邮件、密码重置的代码未校验 Host。检测线索查找TRUSTED_HOSTS配置用法查找url_for(..., _externalTrue)并检查 host 如何确定。修复将TRUSTED_HOSTS设为你预期的域名及所需子域确保外部 URL 生成使用受信任的主机/协议。4.8 反向代理信任FLASK-PROXY-001反向代理信任必须正确配置Severity: Medium若依赖 IP 做认证则为 HighRequired若在反向代理之后MUST 配置 Flask/Werkzeug 仅信任来自预期代理的转发头MUST NOT 盲目信任来自公网的X-Forwarded-*头。不安全模式ProxyFix信任范围过宽或未搞清前端到底有几个代理就应用未经验证地依赖转发头判断 scheme/host。检测线索搜索ProxyFix搜索安全敏感逻辑中对request.remote_addr、request.scheme、request.host的使用。修复以正确的跳数hop count配置ProxyFix或平台特定设置即使在代理后面也保留TRUSTED_HOSTS。4.9 文件处理与路径穿越FLASK-PATH-001防止路径穿越与不安全文件服务Severity: HighRequiredMUST NOT 将用户可控文件路径传给send_file或直接文件 I/OMUST 使用安全文件服务模式——对用户指定路径用send_from_directory基于可信基目录用safe_join拼接可信基目录与不可信路径组件对上传文件名用secure_filename且仍应生成自己的唯一存储名MUST 确保用户上传内容不作为可执行/活动内容提供尤其是 HTMLSHOULD 在几乎任何文件系统路径计算中用safe_join而非os.path.join。不安全模式send_file(request.args[path])open(os.path.join(base_dir, user_path))且user_path不可信在静态 Web 根目录内无限制地提供上传内容。检测线索在文件路由中搜索send_file(、open(、os.path.join(、pathlib.Path(...)/...确认文件名来源请求参数、数据库、头。修复仅从非用户可控的目录基准提供文件上传内容存静态根之外通过受控路由提供始终校验并规范化文件标识符。备注safe_join从werkzeug.security导入。FLASK-UPLOAD-001文件上传必须校验、安全存储并安全提供Severity: HighRequiredMUST 实施上传大小限制应用 边缘MUST 使用白名单与内容检查校验文件类型不能只看扩展名MUST 尽可能将上传内容存储在可执行/静态根之外SHOULD 生成服务端文件名随机 ID并避免信任原始文件名MUST 安全地提供潜在活动格式下载附件除非明确设计为内联。不安全模式接受任意文件类型并内联提供用用户提供的文件名作为存储路径缺少大小/类型校验。检测线索查找request.files[...]处理器检查secure_filename用法及是否与唯一性结合检查文件存储位置与提供方式。修复实施白名单校验 安全存储 安全提供适用时增加扫描/隔离。4.10 注入类防护FLASK-INJECT-001防止 SQL 注入使用参数化查询 / ORMSeverity: HighRequiredMUST 使用参数化查询或底层参数化的 ORMMUST NOT 用字符串拼接 / f-string 拼接不可信输入构造 SQL。不安全模式fSELECT ... WHERE id{request.args[id]}... WHERE name %s % user_input。检测线索grep Python 代码中的SELECT、INSERT、UPDATE、DELETE字符串追踪不可信数据流入 DB execute 调用。修复替换为参数化查询或 ORM 查询 API查询前校验类型如 int 类型的 ID。FLASK-INJECT-002防止 OS 命令注入Severity: Critical 到 High取决于暴露面RequiredMUST 避免用不可信输入执行 shell 命令若必须使用 subprocess——MUST 以列表形式传参而非字符串、MUST NOT 对攻击者影响的字符串使用shellTrue、SHOULD 对任何可变组件使用严格白名单尽可能用纯 Python 或 Python 库替代 subprocess/system 命令不要假设即使shellFalse参数天然安全——命令可能把参数误当作命令行 flag 或其他可信值处理。不安全模式os.system(user_input)subprocess.run(fcmd {user}, shellTrue)把用户字符串传入bash -c、sh -c、PowerShell 等。检测线索搜索os.system、subprocess、Popen、shellTrue追踪 request/DB 数据流入这些调用。修复用库 API 替代 shell 命令若不可避免硬编码命令并白名单校验参数若子命令支持尽量把用户值放在--之后防止被当作命令行 flag 处理。4.11 出站请求SSRFFLASK-SSRF-001防止出站 HTTP 中的服务端请求伪造Severity: Medium注对小型独立项目此风险较低部署进局域网或与同机其他服务共存时最重要。RequiredMUST 将向用户提供 URL 的出站请求视为高风险SHOULD 对任何用户影响 URL 抓取校验并限制目的地主机/域名白名单SHOULD 阻止访问——localhost / 私网 IP 段 / link-local 地址、云元数据端点MUST NOT 允许非 http/https 协议如file:等SHOULD 设置超时并限制重定向。不安全模式requests.get(request.args[url])接受任意 URL 的 Webhook/预览/抓取端点。检测线索搜索带不可信 URL 来源的requests.get/post、httpx、urllib、aiohttp用法识别 URL 抓取功能预览、导入、Webhook 测试器。修复确保 URL 为 http 或 https禁用file:等协议实施白名单与网络出口控制增加严格解析与 IP 解析检查设置超时如非必要禁用重定向。4.12 重定向、HTTP 方法、CORS 与供应链FLASK-REDIRECT-001防止开放重定向Severity: LowRequiredMUST 校验源自不可信输入的重定向目标如next、redirect、return_toSHOULD 使用内部路径或已知域名的白名单SHOULD 优先只重定向到同站点相对路径。不安全模式redirect(request.args.get(next))且无校验。检测线索搜索redirect(并检查location来源。修复仅允许相对路径或白名单域名校验失败时回退到安全默认值。FLASK-HTTP-001安全使用 HTTP 方法不用 GET 变更状态避免 URL 中的机密Severity: MediumRequiredMUST NOT 通过 GET 执行状态变更MUST NOT 将机密放入 URL查询字符串常被日志记录并经 referrer 泄露SHOULD 对状态变更要求 POST/PUT/PATCH/DELETE并在基于 Cookie 认证时应用 CSRF 防护。不安全模式/delete?id...用 GET 实现密码重置 Token 或 API Key 出现在查询参数中。检测线索枚举 GET 路由并检查是否变更状态查找名为token、key、secret、password等的 URL 参数。修复状态变更迁移到非 GET 方法敏感值走安全通道POST 请求体、请求头并加以保护。FLASK-CORS-001CORS 必须显式且最小权限Severity: Medium与凭据配合误配置时为 HighRequired若不需要 CORSMUST 保持禁用若需要——MUST 白名单受信任来源不反射任意 OriginMUST 谨慎对待携带凭据的请求不要将宽泛来源与 Cookie 组合SHOULD 限制允许的方法与头。不安全模式Access-Control-Allow-Origin: *与携带凭据的 Cookie 或过宽访问组合未校验就反射Originflask_cors.CORS(app)使用宽松默认值。检测线索搜索flask_cors、CORS(、Access-Control-Allow-Origin检查supports_credentialsTrue与通配符来源。修复使用严格来源白名单与最小方法/头除非必要不跨源暴露基于 Cookie 认证的端点。FLASK-SUPPLY-001依赖与补丁卫生聚焦安全相关依赖Severity: LowRequiredSHOULD 固定并定期更新安全关键依赖Flask、Werkzeug、Jinja2、itsdangerousMUST 及时响应已知安全通告。审计聚焦示例若在 Windows 上使用不可信路径做文件服务需确认 Werkzeugsafe_join行为不受到 Windows 设备名device-name边界情形影响——这对应 Werkzeug 的safe_joinWindows 设备名漏洞CVE-2025-66221。检测线索检查requirements.txt、锁文件与运行时环境识别安全辅助函数safe_join、send_from_directory的使用位置。修复升级到已修复版本并为受影响行为添加回归测试。五、实用扫描启发式如何狩猎漏洞§5主动扫描时优先使用以下高信号模式开发服务器 / 调试app.run(、flask run、--debug、DEBUGTrue、FLASK_DEBUG机密SECRET_KEY、secret_key、提交的.env、print(config)Cookie / 会话SESSION_COOKIE_SECURE、SESSION_COOKIE_HTTPONLY、SESSION_COOKIE_SAMESITE存敏感值的session[...] CSRF基于 Cookie 认证应用中无 CSRF 检查的 POST/PUT/PATCH/DELETE 处理器XSS/SSTIMarkup(、|safe、未加引号的属性、render_template_string文件send_file(使用用户可控路径open(操作用户路径os.path.join拼入不可信内容上传处理器用用户文件名做路径注入SQL 字符串 格式化后进入.execute(...)subprocess.*、shellTrue、os.systemSSRFURL 来自 request/DB 的requests.get/post或httpx重定向redirect(request.args.get(next))CORSflask_cors.CORS宽松配置带凭据的通配符来源每次都要尝试确认三件事数据来源不可信 vs 可信汇点类型模板 / SQL / subprocess / 文件 / 重定向 / HTTP防护控制是否存在校验、白名单、中间件。这套启发式正好对应当前 skill 的定位——SKILL.md 声明其仅在用户显式请求安全最佳实践指导、安全审查/报告或 secure-by-default 编码帮助时触发且只对受支持语言python、javascript/typescript、go生效不应用于普通代码评审或调试任务。六、与 Skill 工作流的整合报告、修复与通用安全建议该规格文档是 skill 的references/素材最终行为由 SKILL.md 编排两者配套使用时形成完整闭环触发与加载识别项目语言与框架后加载对应 references 文件如本规格报告输出报告以 Markdown 写入security_best_practices_report.md或用户指定位置顶部为简短执行摘要按严重程度分节所有发现用数字 ID 编号关键发现附带一句话影响说明引用代码必须带行号修复流程一次只修一个发现修复代码附带简洁注释说明其依据的安全最佳实践及不这么做的危险性评估对功能的影响与回归风险避免破坏用户项目遵循用户既定的变更/提交与测试流程覆盖Overrides客户项目可能有自身文档/Prompt 要求覆盖某些实践应关注项目内文档中的具体规则被覆盖的实践可向用户报告但不要争辩也可建议在项目文档中记录覆盖原因。此外 SKILL.md 的通用安全建议 与本规格互补值得在写作/审查时一并遵循避免用递增 ID 作为资源的公开 ID改用较长随机 UUID4 或随机十六进制字符串防止用户推断资源数量与猜测资源 ID关于 TLS 的谨慎态度开发工作大多不带 TLS 或由范围外的 TLS 代理提供不要把缺少 TLS报告为安全问题SecureCookie 仅在应用真正走 TLS 时设置否则在本地开发/测试部署非 TLS下会破坏应用可提供环境变量或其他开关覆盖同时避免推荐 HSTS——在不完全理解其持久影响可能导致重大故障与用户锁定时使用很危险通常不建议在 Codex 审查范围内的项目中使用。七、参考来源概述规格文档的结论建立在以下权威材料之上文档记录访问日期为 2026-01-26Flask 官方文档部署到生产环境、调试应用错误、配置处理、安全注意事项、代理配置ProxyFix、会话 APIWerkzeug 文档与安全通告工具函数send_file / send_from_directory / safe_join / secure_filename / 密码哈希、Werkzeugsafe_joinWindows 设备名漏洞通告CVE-2025-66221OWASP Cheat Sheet 系列会话管理、CSRF 防护、XSS 防护、输入校验、SQL 注入防护、注入防护、OS 命令注入防御、SSRF 防护、文件上传、未校验重定向、HTTP 安全头模板安全参考Jinja 沙箱渲染不可信模板、OWASP WSTG 的 SSTI 测试、PortSwigger Web Security Academy 的 SSTI 课程HTTP 语义RFC 9110安全方法语义。在使用本文规则时请牢记所有关键结论都应在当前代码库中得到证据支持——引用文件路径、代码片段与配置值对于在应用代码中不可见的防护代理、WAF、CDN诚实标注为需在运行时/配置核实这正是该安全规格与 skill 所倡导的审计纪律。【免费下载链接】skillsSkills Catalog for Codex项目地址: https://gitcode.com/GitHub_Trending/skills4/skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考