Javascript 我的身份池id有多敏感？

背景

我一直在开发一个前端javascript应用程序，它消耗AWS资源（主要是API网关后面的Lambdas）。API网关资源受IAM保护，应用程序使用Cognito提供的大部分资源

这包括一个启用了未经身份验证的身份的身份池，以及一个Cognito用户池和多个社交和自定义OIDC提供者的联合。Cognito只通过我们的前端javascript代码，使用Amazon的SDK与之交互

未经验证的身份

ID池ID的敏感性适用于我的所有用例，但我最好奇的是未经验证的用例。我们一直在遵循的似乎是：使用Cognito或STS获取IAM密钥，并使用这些密钥访问AWS资源

这一切都很好，但它确实需要我向前端公开我的标识池id。身份池id是为未经身份验证的IAM角色获取IAM密钥所需的唯一工具

理论上，任何攻击者都可以使用我使用的相同Amazon SDK获取我的身份池id并开始滥用我的资源（未经授权的IAM角色允许使用这些资源）

问题

从一般意义上讲，我应该认为一个身份池ID是多么敏感？把这个给别人看可以吗
• 如果我决定它足够敏感，不暴露于浏览器，我该如何处理？我应该把它藏在哪里，怎样才能找到它
• 在任何情况下，我是否应该“烘焙”一种频繁旋转id的方式
• 是否存在（类型）可以公开id的用例，以及不可以公开id的用例

我正在寻找的答案

正如上面链接的答案所指出的，我的理解是，未经验证的身份并不是防弹的，只能提供一个合理的信心水平，即它是你的应用程序。换句话说，虽然并非不可能，但至少有人使用此模型滥用您的AWS后端是相当困难的

除了上面的要点，我很欣赏对这种理解的任何批评。我是否低估了未经认证的IAM访问AWS的安全性？卖得太多了

免责声明

我承认这个问题闻起来很像。我不是询问如何在我的应用程序中硬编码身份池id；这已从web服务获取。但是，它仍然完全暴露在前端，您可以说，从AJAX响应中提取它实际上比从精简的代码中提取更容易

---

我会尽可能严格地锁定未经授权的角色，并且我理解，允许匿名访问内容只能如此安全。

可能重复我关于误解的评论实际上是我的错误。我在读其他一些关于这个话题的问答，而我所指的那个实际上并不是你链接到的那个。很抱歉造成混淆。知道你的池id可以让我做我不应该做的事情，就像任何未经验证的访问一样。感觉上你有合理的顾虑，但你把注意力集中在ID上，因为它恰好存在，所以它实际上只是一个问题。任何其他解决方案都会将相同的问题置于不同的标签下。通过EC2代理匿名请求并在背面签名，现在问题转移到了一个事实，即您在HTML中公开匿名可用的URL。。。然而，您不会问“在我的HTML中公开URL安全吗？”当然，IAM策略允许一些类似于您可能对普通web服务器施加的保护，例如referer检查。显然，referer头不能免于欺骗，但它可以防止有人将您的链接复制/粘贴到另一个网站上公然窃取服务，因为典型的用户无法知道他们需要开始欺骗头才能使另一个网站工作。@Michael sqlbot-感谢您的详细说明，这是质量输入。任何其他解决方案都会将相同的问题置于不同的标签下。我当然会产生共鸣。