如何处理 RESTful API 中的敏感属性(例如密码、信用卡等) [英] How to handle sensitive properties in a RESTful API (such as passwords, credit cards, etc)

问题描述

致力于支持多种超媒体类型和身份验证的 REST 框架.我不确定如何处理的一件事是资源中的敏感值.例如，如果我要在 API 中包含用户管理，我需要一种向客户端公开密码字段的方法，但不显示实际的密码哈希.信用卡也是一样.如果我不这样做，它将违反超媒体约束，因为该领域的知识将变得带外，并使我的 HATEOAS 损坏.

Working on a REST framework that will support multiple hypermedia types and authentication. One thing I'm not really sure how to handle are sensitive values in the resources. For instance, if I were to include user management in the API, I would need a way to expose to the client that there was a field for the password, but not show the actual password hash. Same thing with a credit card. If I don't, it would violate the hypermedia constraint as knowledge of the fields would become out of band, and make my HATEOAS broken.

这是我遇到的一个实际用例:

Here's an actual use case that I've encountered:

该项目是一个展示他们的人员目录，以便其他人可以雇用他们.有两种类型的用户:有配置文件的用户和没有配置文件的用户.围绕资源的设计将是 /users/{userid} 对于用户和 /users/{userid}/profile 或 /profile/{profileid} 将包含一个返回用户的链接，以便客户端可以获取用户姓名等信息.此外，用户还可以将信用卡存储在 /users/{userid}/creditcards/{creditcardid}.

The project is a directory of people that showcases them so others can hire them. There are two types of users: those with profiles, and those without. The design around the resources would be /users/{userid} for a user and /users/{userid}/profile or /profile/{profileid} which would include a link back to the user so the client could get things like the user's name, etc. Also, the user would be able to store a credit card at /users/{userid}/creditcards/{creditcardid}.

要显示用户的个人资料，您还需要用户资源来访问名称等内容.我们不想在用户资源或信用卡链接上公开用户的密码.我想我可以毫无问题地隐藏信用卡链接，但我不确定密码字段.我应该只向授权用户公开它，而不是向其他用户模型公开吗?我应该提到，除非经过身份验证和授权，否则用户只允许使用 GET.

To display a user's profile, you would also need the user resource to have access to the names and whatnot. What we don't want is to expose the user's password on the user resource, or the credit card links. I think I can just hide the credit card links without any issues, but I'm not sure about the password field. Should I just expose it for the authorized user, but not on the other user models? I should mention that only GET is allowed on users unless authenticated and authorized.

强调这一点的一个奇怪的边缘情况是您可以部分访问更改的对象.假设您是一名低级管理员，有权更改用户名和地址，但不能更改密码.由于您无权访问，因此无法公开密码字段.如何对我没有所有字段的资源执行 PUT 操作?在这些情况下，我应该只使用 PATCH 吗?

One weird edge-case that would emphasize this would be an object you have partial access to change. Say you were a low level admin who had access to change the user's name and address, but not password. Since you don't have access, you can't expose the password field. How can I do a PUT to a resource that I don't have all the fields to? Should I just use PATCH in those cases?

TL;DR:如何在 REST API 中正确隐藏/公开字段并遵循超媒体约束?

TL;DR: How do I properly hide/expose fields in a REST API and also follow the hypermedia constraints?

推荐答案

首先，当有敏感信息时，始终使用 SSL.如果您使用 SSL，您的请求将被加密.甚至 URL 也是通过网络加密的.但是，在许多其他地方可能会以明文形式记录这些相同的 URL(例如代理服务器、负载平衡器、DNS 服务器)，因此不要在 URL 中放入任何敏感信息.

First, always use SSL when there is sensitive information. If you use SSL, your request will be encrypted. Even the URLs are encrypted over the network. However, there are lots of other places where those same URLs may be logged in clear text (e.g. proxy servers, load balancers, dns servers), so it's important not to put any sensitive information in the URL.

那么这对您的 REST API 意味着什么?嗯，首先，不要在 ID 中使用敏感信息.您的信用卡号可能是唯一的，但不要将其用作卡的标识符.

So what does that mean for your REST API? Well, first of all, don't use sensitive information in IDs. Your credit card number may be unique, but don't use that as the identifier of the card.

此外，在获取资源时永远不要返回密码.您应该在服务器上过滤掉此类信息.您可以在请求正文中接受它，但绝不能在响应正文中将其发回.

Also, never return a password when getting a resource. You should be filtering this type of information out at the server. You can accept it in a request body but it should never be sent back in a response body.

对于您的另一个奇怪的边缘情况，PATCH 还不是标准.在它成为一个之前，我已经看到很多人使用 POST 进行部分资源更新.POST 不一定是幂等的，所以它实际上很有意义.因此，POST 是部分更新，而 PUT 是在给定 ID 处创建或替换.好听吗?

To your other weird edge case, PATCH is not yet a standard. Until it becomes one, I've seen a lot of people using POST to do partial resource updates. POST does not have to be idempotent, so it actually makes a lot of sense. So, POST is partial update and PUT is create or replace at a given ID. Sound good?

如果您还没有看过 Les Hazlewood 关于 HATEOAS 的演讲，我建议您观看.它很好地概述了最佳做法.

If you haven't watched Les Hazlewood's talk on HATEOAS yet, I would suggest you do so. It gives a pretty good overview of the best practices.

http://www.youtube.com/watch?v=mZ8_QgJ5mbs

这篇关于如何处理 RESTful API 中的敏感属性(例如密码、信用卡等)的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！