为什么JSON Web令牌（JWT）应该用环境变量签名？

在各种教程中，我发现它们都说“JWTs应该由环境变量签名，而不是硬编码到应用程序中”。从安全角度来看，如果黑客想要访问我的Node.js应用程序的源代码，我假设他们也可以看到服务器系统上的环境变量？从节点内部调用环境变量与硬编码应用程序的源代码相比，如何从本质上更安全？

环境变量只在运行的系统上可用。但是，您的源代码可能位于开发系统上的版本控制存储库（Github、Bitbucket等）中，可能位于许多备份位置，等等

---

从本质上讲，一个环境是可变的，您的源代码可能在多个位置。

这有几个原因

1） JWTs的签名密钥对于每个环境都应该是不同的（例如，您不希望您的开发人员知道您的产品签名密钥）。实现这一点的最简单方法是使用环境变量

2） 您应该从代码库中提取秘密内容。这意味着一个配置文件或环境变量

3） 如果有人能够访问你的信息源，他们至少不会拥有王国的钥匙

---

4） 关注点分离。

但如果我非常小心，在点击“npm开始”之前更改代码库中的变量，是否存在理论上的安全缺陷？显然，出于“人为原因”，最好使用环境变量，以防我忘记更改内容，但我更好奇的是，如果有技术上的安全优势而不是实际的安全优势，那么在第3点上，一个人如何才能访问仅在一个系统上运行的源代码，而不访问系统本身？节点中是否存在漏洞，以便读取后端代码？这是假设，但确实存在--前端web服务器中的漏洞或错误配置可能允许访问源代码，但不允许访问环境变量。或者，如果您的应用程序执行任何与文件系统读写相关的操作，您可能会遇到类似的情况。您是否有关于涉及前端错误配置的安全漏洞的更多信息？不确定您在寻找什么，但主要的可能是使用Apache/nginx提供静态文件，但不锁定目录docroot（或者只是偶然把它指向了错误的地方）有意义。我的目标之一是尝试使我的应用程序尽可能防弹，因此我尝试了解提出安全建议的所有原因和场景。我更想问的是，在可能意外暴露后端代码库的情况下，是否会想到任何文章或资源