下拉安全（dropdown security）

下拉安全（dropdown security）：对象下拉里的"静态值过滤"可能把敏感信息泄露给看不了对象的人。这一篇讲风险怎么产生、后端如何脱敏，以及该用什么来替代静态值。

文档开宗明义地给出了警告：对象下拉校验里的静态值过滤（static value filters），会暴露给所有能查看该动作类型的人。使用这类过滤，可能把"属性值的组合"泄露给无权查看被过滤对象的用户。

缓解办法（mitigation）是：改用对象属性或参数来过滤对象集——因为这些值不会直接显示在界面里。

文档举了个例子：有一个 Document 对象，带 Investigation Name 属性。动作里给对象引用参数加过滤，只显示 Investigation Name = "Area 51 Investigation" 的文档。

问题来了：那些根本看不了这些文档的用户，通过这条过滤，反而知道了"存在一些 Document 对象，其 Investigation Name 是 Area 51 Investigation"。这就是把底层数据的存在性泄露了出去。

而且文档强调：这只适用于静态值过滤。如果过滤改成"按参数过滤"或"按另一个对象的属性过滤"，就不会有这个问题：

• 按参数过滤：参数值由用户提供，不暴露任何底层数据。
• 按对象属性过滤：会尊重该用户对对象的可见性限制。

• 过滤写死 "Area 51 Investigation" → 点此揭晓
• 过滤值来自用户填的 Name 参数 → 点此揭晓
• 过滤值取另一个对象参数的属性 → 点此揭晓

文档解释了后端通常怎么做：在大多数情况下，动作后端会对动作类型定义里的敏感信息脱敏（redact）。例如提交条件（submission criteria）对不能编辑动作类型的用户是隐藏的；同样地，用户既不会在界面里、也不会在后端响应里看到新的对象下拉过滤。

但有一个关键例外：当用户查看动作表单时，下拉校验会被转换成一个对象集（object set）。这意味着用户可以审查包含该对象集的网络请求。在前面的例子里，用户会收到一个带有 Investigation Name = 'Area 51 Investigation' 过滤的对象集 RID——即便他看不了任何对应对象，也暴露了这个属性值的存在。

文档还补了一句：如果"可见性"比"安全性"更让你在意，这条警告可以忽略。下面用一个小实验体会"动作定义"和"表单网络请求"的差异：

把上面的内容收成可执行的建议：

• 用参数或对象属性过滤替代写死的静态值，值不会直接暴露在界面里。
• 敏感字段不要写进过滤值尤其是不希望被人知道"存在与否"的属性。
• 理解"界面不可见 ≠ 网络请求不可见"表单渲染时校验会变成对象集，可能被审查请求的人看到。
• 按风险权衡若可见性优先于安全，文档说该警告可忽略——但默认应保守。