如何在允许对端点进行身份验证的请求的同时阻止对REST API / NGINX服务器的匿名请求？

Question

初始披露：

我一般不熟悉nginx和反向代理配置。

背景

[我有一个由Swagger衍生的，FOSS，https可访问的REST API [由另一方编写]，该API在nginx 1.16.1反向代理后面的EC2 CentOS 7实例的某个端口上运行（至路径https://foo_domain/bar_api/）；就我的目的而言，该API需要从各种各样的服务中获取，而并非所有这些服务都发布其IP范围，即该API必须暴露于来自任何IP的流量。

对API数据端点（例如https://foo_domain/bar_api/resource_id）的访问由位于以下位置的登录功能控制https://foo_domain/bar_api/foobar/login由令牌认证支持，可以正常工作。

问题

但是，问题是匿名用户能够获取

https://foo_domain/bar_api

没有登录，将导致返回有关API服务器配置的潜在敏感数据，例如API的真实端口，服务器版本，某些可用的端点和参数等。为此，从安全观点。

问题

我如何阻止对/ bar_api /端点的匿名GET请求，同时允许对端点beyond / bar_api /的登录和身份验证的数据请求不受阻碍地进行？或者，否则，如何防止此类请求被returned删除？

Answer 1

在这种情况下，一般建议是使用API​​网关。将网关放在最前面可以解决您概述的所有安全问题，此外，它还可以利用它带来一些其他好处，例如速率限制，限制，BOT检测，IP限制等。

典型的API网关包括：

• 安全性（身份验证和可能的授权）
• 管理访问配额和限制缓存（代理语句和缓存）
• API的组成和处理路由（可能是处理）到“内部”
• API API运行状况监视（性能监视）
• 版本化（可能是自动化）

API网关的优势

• 放在一个地方

• 简化了API源代码本身，因为这些问题已被外部化

• 提供API的中央和唯一视图，因此更有可能允许一致的政策

API网关缺点

• 可能的单点故障或瓶颈

• 复杂度风险，因为所有API规则都放在一个位置

• 锁定风险，迁移可能并不简单

我不会建议使用哪个网关，但是有很多可用的开源选项，它们确实很棒。根据您的要求评估其中的几个，然后继续努力。