这些答案中的每个人都忽略了真正的访问控制/授权。

例如，如果您的RESTAPI/web服务是关于发布/获取病历的，那么您可能需要定义访问控制策略，以确定谁可以访问数据以及在什么情况下访问数据。例如：

医生可以获取与他们有护理关系的患者的病历任何人都不能在练习时间之外（例如9到5）发布医疗数据最终用户可以获得他们拥有的病历或他们作为监护人的患者的病历护士可以更新与护士属于同一单位的患者的病历。

为了定义和实现这些细粒度授权，您需要使用一种基于属性的访问控制语言XACML，即可扩展访问控制标记语言。

其他标准如下：

OAuth:id。联合和授权委托，例如让一个服务代表我的另一个服务（Facebook可以发布到我的Twitter）SAML：身份联合/web SSO。SAML非常关注用户是谁。WS-Security/WS-*标准：这些标准关注SOAP服务之间的通信。它们特定于应用程序级消息传递格式（SOAP），它们处理消息传递的各个方面，例如可靠性、安全性、机密性、完整性、原子性、事件。。。没有一个涉及访问控制，所有都是特定于SOAP的。

XACML是技术不可知的。它可以应用于java应用程序、.NET、Python、Ruby。。。web服务、REST API等。

以下是有趣的资源：

OASIS XACML网站NIST ABAC标准

我使用了OAuth几次，也使用了一些其他方法（BASIC/DIGEST）。我衷心建议OAuth。以下链接是我见过的关于使用OAuth的最佳教程：

http://hueniverse.com/oauth/guide/

正如twitt所说，AmazonS3是一个很好的模型。它们的请求签名确实具有一些特性（如包含时间戳），有助于防止意外和恶意请求重放。

HTTP Basic的优点是几乎所有的HTTP库都支持它。当然，在这种情况下，您需要使用SSL，因为通过网络发送明文密码几乎是一件普遍的坏事。使用SSL时，Basic比Digest更好，因为即使调用方已经知道需要凭据，Digest也需要额外的往返来交换nonce值。使用Basic，调用者只需在第一次发送凭证。

一旦确定了客户机的身份，授权实际上只是一个实现问题。但是，您可以将授权委托给具有现有授权模型的其他组件。同样，Basic的好处是，您的服务器最终提供了客户端密码的明文副本，您可以根据需要将其传递给基础架构中的另一个组件。

SOAP世界被安全标准覆盖得很好，这并不意味着默认情况下它是安全的。首先，标准非常复杂。复杂性不是安全性的好朋友，实现漏洞（如XML签名包装攻击）在这里很常见。

至于.NET环境，我不会有太大帮助，但“用Java构建web服务”（一个有约10位作者的砖）确实帮助我理解了WS-*安全体系结构，尤其是它的怪癖。

对于Web应用程序安全，您应该看看OWASP(https://www.owasp.org/index.php/Main_Page)它为各种安全攻击提供了欺骗单。您可以采用尽可能多的措施来保护您的应用程序。关于API安全（授权、身份验证、身份管理），有多种方式（基本、摘要和OAuth）。OAuth1.0中存在循环漏洞，因此可以使用OAuth1.0a（由于对规范的担忧，OAuth2.0没有被广泛采用）

Github上有一个很棒的清单：

身份验证

不要在身份验证、令牌生成和密码存储方面另起炉灶。使用标准。使用登录中的最大重试和监禁功能。对所有敏感数据使用加密。

JWT（JSON Web令牌）

使用随机复杂密钥（JWT Secret）使暴力强制令牌变得非常困难。不要从有效载荷中提取算法。在后端强制算法（HS256或RS256）。使令牌过期（TTL、RTTL）尽可能短。不要将敏感数据存储在JWT有效载荷中，它很容易被解码。

OAuth（身份验证）

始终验证redirect_uri服务器端，以仅允许白名单URL。始终尝试交换代码而不是令牌（不允许response_type=token）。使用带有随机哈希的状态参数来防止OAuth身份验证过程中的CSRF。定义默认范围，并验证每个应用程序的范围参数。

通道

限制请求（限制）以避免DDoS/暴力攻击。在服务器端使用HTTPS以避免MITM（中间人攻击）将HSTS标头与SSL一起使用以避免SSL Strip攻击。

输入

根据操作使用正确的HTTP方法：GET（读取）、POST（创建）、PUT/PATCH（替换/更新）和DELETE（删除记录），如果请求的方法不适合请求的资源，则使用405 method Not Allowed（不允许方法）进行响应。验证请求的内容类型Accept标头（content Negotiation），以仅允许您支持的格式（例如application/xml、application/json等），如果不匹配，则使用406 Not Acceptable响应进行响应。按您接受的方式验证发布数据的内容类型（例如application/x-wwww-form-urlencoded、multipart/form-data、application/json等）。验证用户输入以避免常见漏洞（例如XSS、SQL注入、远程代码执行等）。不要在URL中使用任何敏感数据（凭据、密码、安全令牌或API密钥），而是使用标准的授权标头。使用API网关服务启用缓存、速率限制策略（例如配额、峰值阻止、并发速率限制）并动态部署API资源。

处理

检查所有端点是否在身份验证后受到保护，以避免身份验证过程中断。应避免使用用户自己的资源ID。使用/me/orders而不是/user/654321/orders。不要自动增加ID。请改用UUID。如果您正在解析XML文件，请确保未启用实体解析以避免XXE（XML外部实体攻击）。如果您正在解析XML文件，请确保未启用实体扩展，以避免通过指数级实体扩展攻击造成Billion Laughs/XML爆炸。使用CDN进行文件上载。如果您正在处理大量数据，请使用Workers和Queues在后台处理尽可能多的数据，并快速返回响应以避免HTTP阻塞。不要忘记关闭调试模式。

输出

发送X-Content-Type-Options:nosniff标头。发送X-Frame-Options：拒绝标头。发送内容安全策略：默认src“none”标头。删除指纹标头-X-Powered-By、Server、X-AspNet-Version等。强制响应的内容类型，如果返回application/json，则响应内容类型为application/json。不要返回敏感数据，如凭据、密码和安全令牌。根据完成的操作返回正确的状态代码。（例如200 OK、400 Bad Request、401 Unauthorized、405 Method Not Allowed等）。