我有以下 url 来调用 API Gateway 后面的服务：https://
问题：它足够安全吗？某人说它不安全，因为任何人都可以使用该 url 在 url 后面调用我的服务，而不仅仅是我。一种解决方案是我可以启用 API 密钥并在调用 url 时将 API 密钥附加为请求标头。另一种解决方案是使用AWS Cognito等。
为什么不安全？
我了解 API Gateway 也可以使用 AWS cognito 进行身份验证。即当一个人访问该 url 时，他会被要求输入凭证（用户/密码），但同样，这个凭证也可以被窃取，就像
IMO，使用
我说的对吗？谁能解释为什么拥有 API Gateway 或 AWS cognito 比不使用它们更安全？
与上述问题相关的另一个问题：
由于url使用https，url本身（包括
【问题讨论】：
标签： aws-api-gateway
最重要的安全因素始终是风险。我们永远无法创建一个完全安全的系统，我们只能尝试平衡攻击系统的成本与被破坏的成本。因此，在此之前，我会问：如果有人知道您的 API 的 URL，会有什么风险？
你是对的 - 这是一种最小形式的安全性。仅此而已。
问自己一组问题：
攻击者可以从响应中学到什么？ - 如果您只需要知道某些东西存在就可以开始获取响应，您可以开始测试它以了解它的行为方式。您可以通过限制所有响应来阻止这种情况，但这可能会对您的合法客户产生负面影响，所以您问...
我可以限制攻击者通过响应了解的内容吗？ - 如果攻击者需要更多信息来构建合法请求，您可以限制和约束所有不合法的请求。
问题从那里继续升级。这一切都归结为投资回报率——你所保护的东西的价值是什么，攻击面是多少，被破坏的风险是什么？最重要的是您的客户和用户的信任。 作为专业人士，我们必须保护委托给我们的信息的完整性。
另一个问题是在 HTTPS (TLS/SSL) 下，第三方侦听器受保护哪些不受保护？简短的回答是，如果您请求foo.com/bar，任何想知道的人都可以看到主机名（foo.com），但路径（/bar）不可见；并且 cookie、标头和请求中包含的任何其他内容都是安全的。
【讨论】：
/ 之后的所有内容），以及任何其他请求内容。一个简单的例子：如果我访问foo.com/bar，任何人都可以看到我访问了 foo.com，但他们看不到我访问了/bar，也看不到任何其他详细信息（cookie 等）