保护用Play Framework开发的REST API

我目前正在使用Play Framework 2.3开发REST/JSON API。我目前正在考虑一种有效而简单的方法来保护API。就安全而言，我的意思是有些行动需要最终用户进行认证才能被接受。保护用Play Framework开发的REST API

目前，我依赖于Play Framework会话管理（作为提醒，它将所有会话数据存储在每个查询中发送的签名cookie中 - 因此，它是无状态的，即使cookie可以被客户读取，它不能被更新）。

流程很简单：

最终用户登录感谢API客户端
如果被接受，一个cookie在应答集
当发送下一个查询发送登录查询，API客户端会自动添加cookie，因此最终用户被API识别。

我的问题如下：我是否真的需要进一步提高安全性？我无法找到这个现有的机制不能正常工作的原因...

在此先感谢！ PS：目前我既是API的开发者和消费者，也没有公开发布的计划。

PPS：我正在开发的客户端使用AngularJS

来源

2015-10-19 Nicolas B.

我不明白这个问题，因为“进一步”是非常广泛的。为什么你对自己施加进一步的安全限制，知道你是唯一的消费者？你关心什么 - 只是一般的安全最佳实践，框架安全性的完整性还是其他？ – Chrizt0f

诚如我所说，API并非公开。在这种情况下，这只是为了确保我不会忘记可能导致安全漏洞的一件大事（所以最好的做法是）。但说实话，我的问题也适用于其他使用公共API的案例。 –

看看这篇文章，它解释了在游戏环境中的跨站点请求伪造[18076206]（http://stackoverflow.com/questions/18076206/how-do-i-secure-my-rest-api-developed-in- playframework？rq = 1）和播放自己的[文档]（https://www.playframework.com/documentation/2.4.x/ScalaCsrf）在这个问题上 – Chrizt0f

你并不需要一个简单的Web应用程序。这是正确的解决方案。

您可以认为只有在可用性方面才能使用令牌。

当然我假设你使用https。

来源

2015-10-19 19:24:48

是的，它是基于HTTPs。 –

所以我没有看到使用令牌（JWT）的任何安全原因。不同的方面 - 是的，令牌更“休闲”，更灵活。还有一件关于cookie的文章 - 其他标题甚至有点安全，但只有一点 - 例如“HTTPOnly”和“Secure”等。 –

而不是在Cookie中设置值，您可以尝试使用Http标头x-auth-token。尽管这不是一个遵循的规则，但它是基于Token的身份验证的标准 – Sivailango

保护用Play Framework开发的REST API

回答

相关问题