我有一个带有rails-api后端的项目和一个在单独的nginx服务器上运行的角度repo。前端向API发出正常的JSON请求，但我有一些内部方法，我只想要我们的前端。到目前为止，我一直使用引荐来源保护作为我们前端服务器的白名单，但我知道这可能是欺骗性的。
如何防止攻击者通过这些内部方法创建帐户并使用请求充斥服务器？
我考虑的另一个解决方案是在每个请求上向前端发送CSRF令牌令牌，然后要求前端在每个请求中发送该令牌。我也不喜欢这个想法，因为攻击者每次发出请求时都可以向此端点发出请求以获取CSRF令牌。
我错过了这里明显的一切吗？人们如何解决这个问题？
答案 0 :(得分：1)
我的描述中没有任何内容会使您的用例与常规的非语言化应用程序不同。
如果我有一个常规rails应用程序服务“注册”页面，没有什么可以防止恶意用户编写该页面上无限循环注册的脚本。这似乎是您所描述的问题，但问题似乎不同，因为您在有意识地公开的API与内部使用的API之间的区别。
典型的解决方案是使用验证码或其他东西，以确保在API请求的另一端有一个人。
答案 1 :(得分：0)
前端js源可供任何用户使用。即使是混淆，也可以用于逆向工程。
似乎是您的应用程序架构问题，您的前端允许用户执行一些限制他的操作。
您可能应该在这里提供有关您的应用的更多信息。或者查看和更改应用程序架构。