Dear ImGui 安全模型与漏洞报告指南：理解"可信输入"设计边界

Dear ImGui 的 安全策略 并非一份冗长的安全规范，而是用十余行文字清晰划定了这个轻量级 GUI 库的威胁模型：它面向运行可信代码与可信数据的开发者工具和技术应用，而非作为抵御恶意输入的加固安全边界。读完本文，你将理解 Dear ImGui 的"可信输入"设计前提、它明确不做（也不要求它做）的对抗性加固，源码中用于降低程序员常见错误崩溃的断言与错误恢复机制，以及官方推荐的漏洞报告渠道。

设计定位：为可信代码与可信数据而生的工具库

安全策略的原文开篇即给出核心前提：

Dear ImGui is primarily designed for developer tools and technical applications running trusted code and trusted data. （Dear ImGui 主要为运行可信代码和可信数据的开发者工具及技术类应用而设计。）

这一定位决定了整个库的安全假设：

• 可信代码（trusted code）：UI 代码由应用开发者自己编写，API 调用序列（Begin/End、PushFont/PopFont 等配对调用）由开发者在编译期就能确定；
• 可信数据（trusted data）：渲染到界面里的字符串、数值来自应用自身的逻辑，而不是来自网络上传入的未经验证的内容。

在这个前提下，库把工程精力集中在 安全策略 中明确声明的方向上：

开发工作聚焦于改进真实应用中的开发者体验、易用性、正确性与健壮性，并尽最大努力减少由常见程序员错误导致的崩溃。

为什么不宜将其作为安全边界

文档紧接着给出了最关键的一条使用禁忌，这也是整份安全策略中对用户行为约束最强的部分：

该库并非作为对抗敌意或刻意畸形输入的加固安全边界而设计： 请考虑不要在"崩溃（例如由刻意畸形输入引起）可能导致提权"的场景中使用它。 例如：在一个特权进程中运行，并与非特权客户端交互，且这些客户端会向 Dear ImGui 输送代码或数据。

把这句话翻译成具体的架构风险：

风险场景	为什么危险
特权进程（root/admin 权限）中内嵌 ImGui UI，渲染来自外部非特权客户端的字符串	畸形输入触发的崩溃或内存错误发生在高权限进程内，等于给了低权限方一个潜在的提权/拒绝服务通道
将未校验的外部二进制数据直接当作纹理 ID、尺寸参数传入渲染后端	崩溃后果由宿主进程承担，宿主进程权限越高，后果越严重
把 ImGui 当作解析不可信协议（如网络消息、脚本）的"前端"	库的断言与错误恢复机制针对的是编程错误，不是恶意构造的对抗输入

反过来说，以下场景与文档的威胁模型完全吻合，可以放心使用：IDE/调试器等开发者工具、引擎编辑器、内部运维面板、单机技术软件——即输入源与 UI 代码同属开发者可控范围的场合。

开发边界的另一半：明确不做什么

安全策略 同样坦诚地声明了项目不会专门投入的方向：

本项目不会专门聚焦于：对抗性模糊测试（adversarial fuzzing）场景、内存分配失败加固（allocation-failure hardening）、以及正常使用中几乎不可能出现的极端人为边缘情况。

这意味着三件事，评估依赖 Dear ImGui 的产品时需要纳入考量：

1. 不对抗恶意模糊测试：用 libFuzzer/AFL 之类的工具向库投喂畸形字节流找到的越界或崩溃，通常不在项目关注的修复范围内——除非它们也是真实编程错误路径；
2. 不保证 OOM 下的优雅降级：代码假设 ImVector、ImVector<T> 的扩容和 new/realloc 路径成功，分配失败不会被视为需要处理的安全状态；
3. 不为"理论上可达但现实中不会发生"的输入分支写防御代码：库追求的是"bloat-free"（无臃肿）与高性能，这类防御代码本身就是一种开销。

源码印证：针对"程序员常见错误"的降崩溃机制

文档承诺"尽力减少常见程序员错误导致的崩溃"，这一点在源码中有清晰的落地。Dear ImGui 区分了两类断言：

普通断言 IM_ASSERT——用于库内部不变量，默认就是标准 assert，可在 imconfig.h 中覆盖：

// imgui.h 第 96 行
#define IM_ASSERT(_EXPR)    assert(_EXPR)    // You can override the default assert handler by editing imconfig.h

可恢复的用户错误断言 IM_ASSERT_USER_ERROR 系列——用于开发者误用 API 的场景，走"先记录错误日志、可恢复继续运行"的路径。定义见 imgui_internal.h：

#define IM_ASSERT_USER_ERROR(_EXPR,_MSG)            do { if (!(_EXPR)) { if (ImGui::ErrorLog(_MSG)) { IM_ASSERT((_EXPR) && _MSG); } } } while (0)
#define IM_ASSERT_USER_ERROR_RET(_EXPR,_MSG)        do { if (!(_EXPR)) { if (ImGui::ErrorLog(_MSG)) { IM_ASSERT((_EXPR) && _MSG); } return; } } while (0)
#define IM_ASSERT_USER_ERROR_RETV(_EXPR,_RETV,_MSG) do { if (!(_EXPR)) { if (ImGui::ErrorLog(_MSG)) { IM_ASSERT((_EXPR) && _MSG); } return _RETV; } } while (0)

注意宏的三层结构：条件不成立 → 调用 ImGui::ErrorLog 记录并（在调试器连接时）返回是否放行 → 放行后才触发 IM_ASSERT 中断。这正是 安全策略 所说"减少崩溃"的机制：常见的配对调用错误会先在 ImGuiContext 的错误日志中留下痕迹，而不是直接让进程死掉。

imgui.h 中的 ImGuiContext 配置项进一步暴露了这条策略：

// - Functions that support error recovery are using IM_ASSERT_USER_ERROR() instead of IM_ASSERT().
bool    ConfigErrorRecovery;                // = false      // (WIP) Error Recovery: attempt to recover, continue and not crash after error/s.
bool    ConfigErrorRecoveryEnableAssert;    // = true       // Enable asserts on recoverable error.

[imgui.cpp](https://gitcode.com/GitHub_Trending/im/imgui/blob/7e0de0e411f8ac43ab19603ce64994015f1f12c3/imgui.cpp?utm_source=gitcode_repo_files) 中有大量这类"常见误用"检查的实际用例，例如：

• imgui.cpp#L6101：IM_ASSERT_USER_ERROR_RET(g.WithinFrameScope, "Forgot to call ImGui::NewFrame()?") —— 忘记在 NewFrame() 前 EndFrame()；
• imgui.cpp#L8351：IM_ASSERT_USER_ERROR(g.CurrentWindowStack.Size > 1, "Calling End() too many times!") —— Begin/End 配对失衡；
• imgui.cpp#L9319：IM_ASSERT_USER_ERROR(g.FontStack.Size > 0, "Calling PopFont() too many times!")；
• imgui.cpp#L8492：PopTextWrapPos() 调用次数超过压栈次数。

这些断言检查的全部是编译期就能静态确定的 API 误用，与"对抗运行时恶意数据"是两回事——与 安全策略 的表述完全自洽。如果你的应用需要在出错时绝对不中断（例如长时间运行的工具），可以研究 ConfigErrorRecovery 相关配置项；但请注意源码中 ConfigErrorRecovery 仍标注为 (WIP)，从源码结构看该能力尚在演进中，启用前应以当前版本实际行为为准。

漏洞报告渠道：GitHub Issues 优先，隐私披露走邮件

安全策略 的"Reporting a Vulnerability"一节给出了双通道报告机制，与其"不做对抗性加固"的定位相呼应：

基于上述策略，大多数问题可以直接在 GitHub Issues 中报告。 如果你有隐私披露的理由，请联系 README 中列出的联系邮箱。

对应的联系邮箱在 docs/README.md 中明确给出：

E-mail: contact @ dearimgui dot com

使用建议：

• 默认路径：崩溃、内存错误、API 行为异常等问题，直接在仓库 Issue 跟踪器提交，附上可复现步骤——项目方对"真实应用中出现的错误"响应积极；
• 隐私路径：若问题涉及尚未公开的信息（例如企业内部的派生代码缺陷），按文档说明使用上述邮箱进行私下联系；
• 注意预期管理：如上文所述，纯粹由对抗性模糊测试构造出的"漏洞"报告，与项目的关注范围不符，报告时建议说明它是否同样对应一个真实使用场景下的错误。

小结：把安全策略当作依赖评估清单

决策点	依据（docs/SECURITY.md 及相关源码）
应用输入是否全部可信（开发者可控）？	是 → 符合设计威胁模型；否 → 需自行在边界处做输入校验，或重新选型
UI 是否运行在特权进程中？	是且接收外部数据 → 文档明确建议避免，崩溃可能升级为提权风险
是否要求 OOM 安全/抗模糊测试？	项目明确不专注此类场景，不应作为选型前提
遇到 API 误用崩溃怎么办？	参考 IM_ASSERT_USER_ERROR 错误日志（imgui_internal.h#L2119）定位具体误用
发现安全问题怎么报？	默认 GitHub Issues；隐私场景联系 README 中邮箱

Dear ImGui 的安全模型可以概括为一句话：它假设你信任自己的输入，并要求你在不信任的边界之外自建防线。理解并遵守这一边界，是把它安全地用于生产环境的前提。