必须说一个明确知道自己想要什么的人写的自我解释性问题。你已经得到了一些很好的回应，贡献我的便士如下。

1. 开发人员/测试人员（员工）可以访问代码库是非常常见的，但是应该采取预防措施，例如如果存在任何加密密钥，它们就不是普通代码的一部分，代码中没有纯文本密码等。
2. 最佳实践是让人们只能访问他们履行职责所需的信息，仅此而已，否则可能会导致数据泄露/违反机密性/违反最小特权原则等。
3. 如果攻击者可以看到他们不应该/不允许使用的客户端代码，他们将能够根据可用数据（例如表单名称、字段的名称和数据类型、查询它们的顺序、任何默认值、开发评论等。相信我，如果我掌握了所有这些细节，没有什么能阻止我努力关闭网站）
4. 是的，如果目前是这种情况，那么应该立即解决。
5. 如果这是一个开放软件，那么还有一些场景需要考虑，例如代码中是否存在敏感数据（用户名-密码、加密密钥、外部通信详细信息等）？如果是，那么这必须在每个人都无法访问的存储库中处理。如果您要为员工提供开发环境，则为这些（数据清理）创建虚拟值，然后将其推送给人们。
6. 这都是关于代码存储库、数据/应用程序的，并且从数据库和代码的角度来看，将有用于隔离访问的角色、组和权限，如果不这样做将导致缺少功能级别的访问控制（你不会想要那个）。

好吧，我写的太多了，总结一下，如果你保持应用程序的原样，你就会让攻击者（内部/外部）保持乐观，因为应用程序容易受到所有 OWASP 前 10 大风险的影响。

解决方案（您从未问过他们，但我不想保持循环畅通）

1. 单独的配置代码存储库，在开发环境中使用虚拟配置。
2. 切勿在生产环境中为不应该看到的人保留任何开放/可读的内容。
3. 即使它现在看起来是开放的，一旦它对外部开放，您将需要权限和访问控制措施，现在就实施它们，您不必担心在一两年后代码会增长时修改架构。
4. 不要在对攻击者来说是金矿的生产页面上提供线索/评论/代码。
   5. 遵循 OWASP 十大风险处理指南。

我可以添加更多，但我觉得这些足以满足现在的需要。

如果攻击者可以看到不应该/不允许使用的客户端代码，对攻击者有什么好处？

如果攻击者可以访问客户端代码并因此访问可能执行的请求，则可能更容易利用 CSRF 或缺少访问控制等漏洞。

也可能更容易找到 XSS 等漏洞。XSS 等漏洞现在也可能针对低权限用户和高权限用户，因为两者都可以访问 UI。

暴露这样的功能是我应该立即解决的一个非常糟糕的做法吗？

并不真地。如果不需要，我不会公开它，因为上面列出的原因。

如果我们假设这是一个开放软件（目前从员工的角度来看它是），隐藏特权用户的工具是否只是某种隐蔽的安全性，因为攻击者无论如何都可以检查源代码？

如果它是开源的，它甚至不是默默无闻的安全性，并且隐藏它并不是绝对必要的（尽管仍然不是一个坏主意，特别是因为有可能利用 XSS 漏洞）。

如果攻击者可以看到不应该/不允许使用的客户端代码，对攻击者有什么好处？

即使黑客不被允许/无法使用他们看到的代码，他们仍然可以获得额外信息的好处，他们随后会使用这些信息来攻击您的网站。一个特别有价值的信息来源是客户端包含的 JavaScript 信息。如果黑客看到如何：

1. 您的代码的结构
2. 输入被处理
3. 处理客户端事件

他或她基于这些信息获得有价值的信息来利用您的网站。