跳转至

API 安全 — 认证、授权、加密、日志

这一章讲什么: 一个对外开放的 API,等于一扇对着互联网开着的门。 书里开篇给的两个数先把危机感立住:当前约 83% 的 Web 流量经过 REST API,而部署它们的组织里近 40% 在过去一年里经历过 API 安全事件1。 这一章把防护拆成四根支柱——认证(你是谁)、授权(你能做什么)、加密(路上别人看不看得懂)、日志(出事能不能回放)——并且回答贯穿全章的一个问题:这些事该写在业务代码里,还是放在业务代码前面?

1. 顶层全景:机场类比与四支柱

书里用机场安检做类比,四个环节一一对应2:

  机场环节                API 安全支柱         回答的问题
  ─────────────────────────────────────────────────────
  办票时出示身份证换登机牌   认证 Authentication   你是谁?
  登机牌限定登机口和舱位     授权 Authorization    你被允许做什么?
  行李箱上锁,只有你有钥匙   加密 Encryption       路上别人看不看得懂?
  到处装的监控摄像头        日志 Logging          出了事能不能回放?

  图说:单一环节挡不住所有威胁——四根支柱要叠在一起,才叫纵深防御。

这个类比的深层用意是全章的架构主张:这四件事不该散落在业务代码里,而应该集中在中间的层里做。REST 的四条基本约束(客户端-服务器、无状态、可缓存、统一接口)只负责让交互可扩展,「by design」不解决安全问题;作者 explicitly 把分层(layering)称作第五条约束——代理、网关这些中间件(intermediaries,插在客户端和服务器之间的程序)在中间完成认证、授权、加密、监控,业务代码不用为此重写3。

另外两个概念先钉死,后面全章要用:

  • 认证 vs 授权,一句话区分:认证验身份(通过密码、令牌确认你是谁),授权定范围(你这个身份能对哪些资源做什么、在什么条件下)4。
  • 匿名请求没有问责:没有身份的流量让恶意者可以不留痕迹地狂刷端点、耗尽资源。所以书里建议端点至少要有基础认证——「让每请求可追溯」是安全的地基5。

本章的主线例子:Alice 要调 /protected 这个端点

后面每一节都从同一个具体场景出发:用户 Alice(密码 password123)要访问一个受保护的 API 端点,每一节回答一层障碍——服务器怎么认出她(认证)、认出之后允许她干什么(授权)、她和服务器的对话路上会不会被偷看(加密)、事后怎么查谁做了什么(日志)。每一步旁边都有具体的请求头、编码串、状态码。

2. 认证:从 Basic 到 Bearer 再到 JWT

Basic 认证:简单到裸奔

Basic 认证 1999 年由 RFC 2617 定成标准,机制只有三步:把用户名和密码用冒号拼起来,做 Base64 编码(把任意字节换成 64 个安全字符的一种文本编码——它只是编码,不是加密,谁都能原样译回),放进 Authorization 头发给服务器6。主线例子走一遍:

  Alice 的凭证:   alice : password123
  拼起来:         alice:password123
  Base64 后:      YWxpY2U6cGFzc3dvcmQxMjM=
  请求头:         Authorization: Basic YWxpY2U6cGFzc3dvcmQxMjM=

  服务器端:发现 Authorization 头 → Base64 解码 → 按冒号拆开 → 校验
  失败回:        401 Unauthorized(没带凭证或凭证不对)
                 403 Forbidden(凭证对,但这事你不许做)

  图说:这套机制的真实安全级别≈明文。书上原话:Base64 encoding provides no security,
  only transport compatibility(只保证网络传输不出乱码,不保证秘密)。

书里有句不能滑过去的话:HTTP 发的是明文,HTTPS 才加密——没有 HTTPS,凭证在网上裸奔,会被嗅探(packet sniffing,旁听网络流量)或中间人攻击(MITM,有人冒充服务器截住你的连接)拿走;即使上了 HTTPS,Basic 仍怕重放攻击(replay:截获的凭证可以原样再用,除非配短期令牌或挑战-应答机制)7。另外 Basic 还有个性能暗伤:每个请求都要查一次用户库做密码比对,流量一大,用户库先被打垮8。

Bearer 认证:把密码换成短命的令牌

Bearer 认证的机制一句话:谁持有令牌,谁就能通行(possession grants access)。服务器验过密码一次后,发一个短期、不透明的令牌;之后客户端每个请求都带 Authorization: Bearer 头加那枚令牌,服务器只做令牌的密码学校验,不再碰用户库——把「每次请求一次数据库密码比对」换成「一次性的签名验证」,低端机器上每秒也能验成千上万次9。

但「谁持有谁通行」是把双刃剑:令牌掉进坏人手里,就能冒充 Alice 直到过期。对策书里给了两个:把令牌寿命压短(缩短作恶时间窗)和配 refresh token(刷新令牌)——一种专门用来换新令牌的凭证,免得用户为了续期反复输密码10。

JWT:会自己带证据的令牌

JWT(JSON Web Token)是目前的主流格式,它把 Basic 的两个病根一起治了。结构是三段用点号拼起来的 Base64(主线例子里那个长串拆给你看)11:

  eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyLCJleHAiOjE1MTYyNDkwMjJ9.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
  │                                    │                                                          │
  头(Header)                          载荷(Payload)                                             签名(Signature)
  { "alg": "HS256",                   { "sub": "1234567890",    ← 主体:用户 ID
    "typ": "JWT" }                       "name": "John Doe",   ← 自定义声明
                                         "iat": 1516239022,    ← 签发时间(Unix 秒)
                                         "exp": 1516249022 }   ← 过期时间:正好签发后 10000 秒

  签名 = 用私钥对 base64(头) + "." + base64(载荷) 做散列再加密

  图说:三段里前两段谁都能读(Base64 不保密,所以载荷里别放密码);
  第三段是防伪章——任何改动都会让校验失败,服务器端拒收被篡改的令牌。

要点在签名:服务器用私钥给「头 + 载荷」的散列值(散列就是把任意数据压成定长指纹的运算,改一个比特指纹全变)加签;之后的任何篡改都会让重算的散列和签名对不上,服务器直接拒收。这就是为什么验 JWT 不用查数据库——证据就带在令牌自己身上,这就是「无状态校验」12。这也让 Basic→Bearer→JWT 的迁移故事完整了:Basic 每个请求查库、密码长期暴露;JWT 一次性验证、短期有效。

主线例子的完整时序(书里配图的那条流程):Alice POST /authenticate 带 Basic 头 → 服务器查身份库(这一步最贵)→ 回一个 JWT access_token → 之后 Alice 每个请求带 Authorization: Bearer <JWT> → 服务器只做签名验证,不再查库13。

3. 授权:RBAC、ABAC 与 OAuth scope

RBAC:按角色发权限

RBAC(Role-Based Access Control,基于角色的访问控制):权限不直接授给个人,而是授给角色(管理员、编辑、访客),人挂进角色。一个简单层级:编辑能增删改查,访客只能读,管理员全权。书里给的角色树例子:组织 → 分部 → 设施 → 资源,管理员的读写权限从根向下贯通,编辑的权限只到设施层,访客只有只读、够不到上层14。

RBAC 的四大好处书里列得很实:管理开销小(给新人挂角色就行,不用重设权限)、不易过度授权(权限收拢在角色里)、可审计(能证明「哪些角色碰过哪些敏感数据」——合规刚需)、随组织增长扩展15。它的病也明确:角色爆炸(role explosion)——动态环境里频繁的临时授权需求会逼你不停造新角色,最后角色多到管不过来;它对「看情况」的访问需求(只在工作时间内、只从某个网段)天生僵硬。药方是 ABAC16。

ABAC:按属性当场判

ABAC(Attribute-Based Access Control,基于属性的访问控制):不看你是什么角色,看这次请求的属性——用户位置、一天中的时间、设备类型,由策略(policy,一组「如果……就允许」的规则)实时判定。书里的例子:某 API 只允许特定 IP 网段在办公时间内访问;医院只允许特定医护人员在特定时段调阅特定病历。属性多、环境多变的云环境是它的主场17。

代价也说透了:复杂。策略的定义和管理本身成了重活(大系统里可能有几百条策略),每个请求都要逐条比对,计算开销实打实。实务上 RBAC + ABAC 混用:角色扛结构化的主体分工,属性补具体处境18。

OAuth 2.0 scope:把权限切到「这次任务需要的粒度」

OAuth 2.0 的 scope(权限范围)是另一把尺:[read:data] 只允许读,[write:data] 允许改;scope 直接写进令牌声明里(如 JWT 带 scope: [update:profile]),服务器验令牌时就知道边界,不用再查库。OpenID Connect 把 scope 声明标准化,跨身份提供方通用19。

scope 的申请机制走一遍(主线例子续):客户端向令牌服务要令牌时,可以只申请需要的 scope——这是自我限制,万一令牌泄露,杀伤力被预先关进笼子。请求长这样20:

  POST example.api.com/oauth/token?grant_type=client_credentials&scope=X  (示例省略协议头)
  Authorization: Basic dXNlcjpwYXNz

  图说:令牌服务认出客户端的 A、B、X 三个权限,但请求只要 X → 只发带 X 的令牌。
  书里的机场版:旅客(客户端)在贵宾柜台(授权服务器)亮出会员卡(Basic Auth),
  要求「优先登机 + 贵宾厅」(scope=A,B),但柜台只核到普通登机权(只批 X)——
  登机牌(令牌)上白纸黑字印着已核权限(scope 声明),到贵宾厅门口(网关)一查,
  没有就是 403 Insufficient Scope。伪造登机牌没用,权限都在系统里留了痕(审计日志)。

书里特意点了一个反模式:过度宽泛的通配 scope(如 [delete:*])会把破坏力直接送给恶意用户——scope 设计的第一原则是最小够用21。scope 还能与 RBAC/ABAC 叠加:角色定大方向,scope 在角色内再切(编辑可以 publish:articles 但不给 delete:users),属性再补条件(「财务部的令牌 + read:reports scope」才放行财务记录)22。

4. 加密:TLS 让路上的数据看不懂、改不了、对面是真的

授权管「谁能做什么」,加密管「传输本身可不可信」,两者合起来才是完整的安全系统23。主线例子的传输层:Alice 的 API 请求走 HTTPS(HTTP over TLS,TLS 是 SSL 的现代化继任者,负责在客户端和服务器之间建加密隧道)。没有它,数据明文传输,中间人随便看24。

书里把 TLS 拆成三件保证:

保证 机制 防什么
机密性 传输加密,截获也读不懂 嗅探、MITM 偷看凭证和 API key
真实性(服务器认证) 服务器出示数字证书(由证书权威机构 CA 背书的身份凭证),客户端对照可信 CA 列表验明正身 有人冒充 API 服务器收数据
完整性 MAC(消息认证码)/散列函数做「数据指纹」,接收方重算比对,不一致就拒收 途中数据被篡改(金融转错账、病历被改诊断)

高安全场景(如银行)再加 mTLS(mutual TLS,双向 TLS):客户端也出示证书,双方互验身份。代价书里没藏:证书管理(签发、续期、吊销)是真金白银的运维成本,私钥必须死守25。

5. 日志:从排错工具到取证证据

最后一根支柱最容易被当成「副产品」。书里的定位:日志不止是 debug 后端请求的工具——结构化、有心的日志是谁、在何时、访问了什么的法证记录,是安全事件的回放带26。

记什么:认证尝试(失败登录能暴露暴力破解——撞库狂试密码)、授权决定、时间戳(标记时刻的一串数字)、用户 ID、源/目的 IP、动作(哪个 HTTP 方法)。原则:均衡——记太多是噪音,记太少查无可查27。

怎么记(主线例子的日志条目):

{
  "timestamp": "2034-02-20T14:23:45Z", "level": "ERROR", "service": "payment-api",
  "event": "failed_authentication", "user": "admin@example.com",
  "ip": "203.0.113.12", "endpoint": "/api/v1/transactions",
  "status_code": 401, "message": "Invalid API key"
}

结构化(JSON)而非自由文本,是为了让集中式日志系统(书里点了 ELK——Elasticsearch、Logstash、Kibana 三件套,和 Splunk)能自动做实时监控、告警和趋势分析;接入 SIEM(安全信息和事件管理,专门吃日志做威胁检测的系统)后,一条「可疑的连续事件」能自动触发告警28。

四条铁律(书里直接列的):永不记录密码、API key、个人敏感信息(PII)——泄露的日志是黑客的金矿;结构保持一致(一个服务 JSON 一个服务裸文本,日志关联就断了);日志当敏感数据管(加密、限制访问、监控未授权访问);定留存策略(永存贵且不合规,删太快又没了法证)29。

6. 作者的判断与证据

  • 两个开篇统计(83% 流量、40% 组织遇袭)没有给出来源——这是全书最需要警惕的一类数字:语气是「调查说的」,但没有脚注。我们在边界一节如实标注。
  • 「分层是第五条约束」是作者的主张,严格说不合 Fielding 原意(Fielding 的分层约束讲的是中介组件对两端的透明性,不等于安全网关)。但作为工程主张它完全成立且是行业事实——API 网关挡在前面做认证/限流/日志,业务代码无感。读的时候知道这是作者的再诠释,不是 REST 原教旨。
  • Basic→Bearer→JWT 的演进是本章的叙事主轴,这个次序是业界共识,不是作者偏好;每个环节的代价(重放、查库压力、令牌泄露窗口)书里都如实讲了,没有为叙事牺牲诚实。
  • RBAC/ABAC 的取舍讲得公允:两种模型的病都点到了(角色爆炸、策略复杂),还给出了混用建议——这是本章最实务的一段。

7. 边界与局限

  • 没有攻防。 这是概念巡览章,不是安全实战章:OWASP API Top 10(业界公认的 API 十大风险清单)只出现在第 8 章延伸阅读里;注入攻击、越权访问(IDOR)、限流(rate limiting)、漏洞补丁管理这些 API 安全日常一个字没提。把它当「安全第一课」,别当「安全全部」。
  • 开篇统计无出处:83% 与 40% 两个数无法回核,引用时注意。
  • JWT 的风险讲了一半。 「载荷明文可读、别放秘密」提了;但签名被掉包的攻击(alg:none 陷阱:骗服务器「这段不用验签」)、令牌太大塞爆头、撤销难(发出去没到期就收不回)这些 JWT 著名坑没讲——真用 JWT 前需要补这些。
  • OAuth 2.0 只讲了 scope 这一件。完整的授权流程(用户怎么同意、客户端怎么拿令牌)、PKCE 这些内容不在本章;它也没有提醒「OAuth 2.0 本身不规定令牌格式」这个重要事实。
  • 机场类比是好台阶不是证据:类比帮助记住分工,但真实系统里四支柱的部署位置(网关在分层里的位置、mTLS 的双向成本)比类比复杂。

8. 可带走的

本章主线例子一行走完: Alice 带 Authorization: Basic YWxpY2U6cGFzc3dvcmQxMjM= 调 /protected(服务器查库,401/403 分界);换成 Bearer 后她拿短期 JWT(sub/exp 写进载荷,私钥签名防篡改),之后每个请求只验签不查库;她的编辑角色(RBAC)允许发布文章,ABAC 加「只在工作时间」的限定,scope 进一步只批 publish:articles;全程 HTTPS 加密,failed_authentication 事件带着时间戳和 IP 落进集中日志。

  1. 认证 ≠ 授权:身份(你是谁)与范围(你能做什么)是两道独立的门,都得有人守。
  2. Base64 是编码不是加密——Basic 认证的安全感是错觉;没有 HTTPS,一切归零。
  3. Bearer 的核心是「持有即通行」:令牌必须短期 + 可刷新,泄露窗口压到最小。
  4. JWT 的价值是无状态:签名自带证据,验令牌不用查库;代价是载荷谁都能读、发了收不回。
  5. 权限设计三件套按序上:RBAC 扛组织结构 → ABAC 补具体条件 → scope 切任务粒度;最小够用是铁律。
  6. 通配 scope 是自杀开关([delete:*] 级别的授权别给)。
  7. TLS 给三样:机密、真实、完整;银行级场景上 mTLS,但要先算证书运维的账。
  8. 日志四条铁律:不记秘密与 PII、结构一致、当敏感数据管、有留存策略。
  9. 安全活在这些层里:网关和中间件挡在前面,业务代码才不用每行都设防——这就是「分层」作为第五条约束的工程含义。

9. 原文地图

主题 原书章 原文位置
83% / 40% 两个统计 API Security text/13-fm-introduction.txt:41(搜「83%」)
机场类比 API Security text/13-fm-introduction.txt:38(搜「boarding pass」)
分层作为第五条约束 API Security text/13-fm-introduction.txt:35(搜「a fifth REST constraint」)
匿名请求缺问责 API Security text/13-fm-introduction.txt:73(搜「lacking accountability」)
Basic:Base64 三步与 RFC 2617 API Security text/13-fm-introduction.txt:79(搜「RFC 2617」) · :82(搜「concatenates」) · :91(搜「YWxpY2U6」)
Basic 无安全性与重放 API Security text/13-fm-introduction.txt:109(搜「no security」) · :203(搜「replay attacks」)
Bearer:短期令牌与验签性能 API Security text/13-fm-introduction.txt:209(搜「ephemeral keys」)
JWT 三段结构与签名 API Security text/13-fm-introduction.txt:221(搜「eyJhbGci」) · :227(搜「Header (algorithm」) · :269(搜「tamper proof」)
令牌泄露对策:短期 + refresh token API Security text/13-fm-introduction.txt:272(搜「Refresh tokens」)
Basic→Bearer 时序 API Security text/13-fm-introduction.txt:285(搜「/authenticate」)
认证与授权之分 API Security text/13-fm-introduction.txt:291(搜「verifies an identity」)
RBAC:层级、优点、角色爆炸 API Security text/13-fm-introduction.txt:297(搜「administrator, editor, or viewer」) · :300(搜「administrative overhead」) · :316(搜「role explosion」)
ABAC:属性与策略、复杂性 API Security text/13-fm-introduction.txt:322(搜「user location, time of day」) · :325(搜「complexity」)
OAuth scope 与令牌声明 API Security text/13-fm-introduction.txt:331(搜「read:data」) · :334(搜「scope: [update:profile]」)
scope 申请机制与通配反模式 API Security text/13-fm-introduction.txt:346(搜「grant_type=client_credentials」) · :349(搜「a kind of filter」) · :334(搜「delete:*」)
机场版 OAuth 剧本 API Security text/13-fm-introduction.txt:352(搜「lounge perks」) · :355(搜「403 Insufficient Scope」)
TLS:机密、真实(CA/mTLS)、完整 API Security text/13-fm-introduction.txt:367(搜「clear text」) · :373(搜「certificate authorities」) · :376(搜「mutual TLS」) · :382(搜「fingerprint」)
日志:记什么、结构化、铁律 API Security text/13-fm-introduction.txt:397(搜「brute force」) · :406(搜「sample log entry」) · :445(搜「Never log passwords」)
结论:REST 约束的反讽 API Security text/13-fm-introduction.txt:272(搜「mainstay」) · :454(搜「attack vector」)

  1. 出处:「CHAPTER 6 API Security」第 41 段(text/13-fm-introduction.txt:41,搜「83%」)。原文:「Nearly 83% of current web traffic goes through REST APIs, and almost 40% of organizations hosting them have suffered an API security incident in the past year alone.」——注意:原文未给出统计来源。 ↩

  2. 出处:「CHAPTER 6 API Security」第 38 段(text/13-fm-introduction.txt:38,搜「boarding a flight」)。原文四个环节一一对应:凭证换令牌如 ID 换登机牌;授权如登机牌限定登机口;加密如行李箱上锁;日志如监控摄像头。 ↩

  3. 出处:「CHAPTER 6 API Security」第 35 段(text/13-fm-introduction.txt:35,搜「a fifth REST constraint called layering」)。原文:「This chapter introduces a fifth REST constraint called layering, which deploys intermediaries that can safely close security gaps... intermediaries can authenticate, authorize, encrypt, and monitor activity to secure the application.」 ↩

  4. 出处:「CHAPTER 6 API Security」第 291 段(text/13-fm-introduction.txt:291,搜「verifies an identity」)。原文:「authentication verifies an identity (through passwords and tokens), authorization defines an action scope」。 ↩

  5. 出处:「CHAPTER 6 API Security」第 73 段(text/13-fm-introduction.txt:73,搜「lacking accountability」)。原文:「anonymous requests can be thought of as lacking accountability... malicious actors can operate undetected」。 ↩

  6. 出处:「CHAPTER 6 API Security」第 79 段(text/13-fm-introduction.txt:79,搜「RFC 2617」)、第 82 段(text/13-fm-introduction.txt:82,搜「concatenates」)、第 91 段(text/13-fm-introduction.txt:91,搜「YWxpY2U6cGFzc3dvcmQxMjM=」)、第 97 段(text/13-fm-introduction.txt:97,搜「prefixed by the word Basic」)。服务器四步见第 112 段。 ↩

  7. 出处:「CHAPTER 6 API Security」第 109 段(text/13-fm-introduction.txt:109,搜「no security」)与第 203 段(text/13-fm-introduction.txt:203,搜「replay attacks」)。原文:「Base64 encoding provides no security, only transport compatibility」;「basic authentication remains vulnerable to replay attacks... unless combined with additional protections like short-lived tokens」。 ↩

  8. 出处:「CHAPTER 6 API Security」第 209 段(text/13-fm-introduction.txt:209,搜「performance bottleneck」)。原文:「Basic auth validates credentials against a data store on each and every request, which becomes a performance bottleneck in high-traffic environments.」 ↩

  9. 出处:「CHAPTER 6 API Security」第 209 段(text/13-fm-introduction.txt:209,搜「ephemeral keys」)。原文:「bearer tokens function as ephemeral keys that are invalidated after expiration... bearer tokens only need a signature verification which can be done many thousands of times per second, even on a low-end system.」 ↩

  10. 出处:「CHAPTER 6 API Security」第 272 段(text/13-fm-introduction.txt:272,搜「Refresh tokens」)。原文:「someone can impersonate a user until the token expires. Possession grants access. To prevent this eventuality, developers may issue shorter lived tokens... Refresh tokens go hand-in-hand with this approach」。 ↩

  11. 出处:「CHAPTER 6 API Security」第 221 段(text/13-fm-introduction.txt:221,搜「eyJhbGci」)与第 227–266 段(头/载荷/签名三段结构)。样例中的 exp 1516249022 减 iat 1516239022 恰为 10000 秒。 ↩

  12. 出处:「CHAPTER 6 API Security」第 269 段(text/13-fm-introduction.txt:269,搜「tamper proof」)。原文:「The signature component gives tamper proof qualities to the token... any modification of the token will fail a signature check」;「stateless validation without any loss of verifiable content」见第 215 段。 ↩

  13. 出处:「CHAPTER 6 API Security」第 285 段(text/13-fm-introduction.txt:285,搜「POST request to an /authenticate endpoint」)。原文完整描述了时序:凭证比对(贵)→ 发 JWT → 之后每请求只验签,「lowers the computational overhead since signature verification is much cheaper than repeat database access」。 ↩

  14. 出处:「CHAPTER 6 API Security」第 297 段(text/13-fm-introduction.txt:297,搜「administrator, editor, or viewer」)与第 313 段(text/13-fm-introduction.txt:313,搜「Practice A and Practice B」)。层级树:Org → Practice → Facility → Resource,管理员权限从根贯通,编辑到 Facility 层,访客只读且够不到上层。 ↩

  15. 出处:「CHAPTER 6 API Security」第 300 段(text/13-fm-introduction.txt:300,搜「administrative overhead」)。原文列了四利:权限收拢进角色、新人挂角色即可、可审计可合规、随组织扩展。 ↩

  16. 出处:「CHAPTER 6 API Security」第 316 段(text/13-fm-introduction.txt:316,搜「role explosion」)。原文:「RBAC struggles with temporary access to a resource outside of a user's current role, without creating yet another role, leading to role explosion.」 ↩

  17. 出处:「CHAPTER 6 API Security」第 322 段(text/13-fm-introduction.txt:322,搜「user location, time of day, or device type」)与第 325 段(text/13-fm-introduction.txt:325,搜「specific medical personnel」)。 ↩

  18. 出处:「CHAPTER 6 API Security」第 325 段(text/13-fm-introduction.txt:325,搜「combined with RBAC」)。原文:「ABAC can be combined with RBAC to provide a hybrid, adaptive authorization mechanism」;复杂性见同段「Policy definition and management can be cumbersome」。 ↩

  19. 出处:「CHAPTER 6 API Security」第 331 段(text/13-fm-introduction.txt:331,搜「read:data」)与第 334 段(text/13-fm-introduction.txt:334,搜「OpenID Connect」)。 ↩

  20. 出处:「CHAPTER 6 API Security」第 346 段(text/13-fm-introduction.txt:346,搜「grant_type=client_credentials」)与第 349 段(text/13-fm-introduction.txt:349,搜「a kind of filter」)。原文:令牌服务认出 A、B、X,请求要 X,Y,Z,最后只发带 X 的令牌。 ↩

  21. 出处:「CHAPTER 6 API Security」第 334 段(text/13-fm-introduction.txt:334,搜「wildcard」)。原文:「An overly permissive wildcard scope like [delete:*] could grant destructive power to a malicious user.」 ↩

  22. 出处:「CHAPTER 6 API Security」第 337 段(text/13-fm-introduction.txt:337,搜「department finance」)。原文:「a policy can grant access to financial_records only if the user's is department finance and the token's scope includes [read:reports]」。 ↩

  23. 出处:「CHAPTER 6 API Security」第 361 段(text/13-fm-introduction.txt:361,搜「a more complete security system」)。原文:「authorization controls access, and encryption secures a communication channel」。 ↩

  24. 出处:「CHAPTER 6 API Security」第 367 段(text/13-fm-introduction.txt:367,搜「clear text」)。原文:「Data passed through HTTP without TLS is sent in clear text, subject to MITM attacks... TLS prevents this by creating a secure tunnel」。 ↩

  25. 出处:「CHAPTER 6 API Security」第 373 段(text/13-fm-introduction.txt:373,搜「certificate authorities」)、第 376 段(text/13-fm-introduction.txt:376,搜「mutual TLS」)、第 382 段(text/13-fm-introduction.txt:382,搜「fingerprint」)。原文:「There is a cost associated with the added security. Managing certificates can be expensive and requires careful lifecycle management」。 ↩

  26. 出处:「CHAPTER 6 API Security」第 391 段(text/13-fm-introduction.txt:391,搜「forensic records」)。原文:「teams can turn logs into traceable forensic records of who accessed what and when... Without deliberately prepared logs, APIs operate in the dark.」 ↩

  27. 出处:「CHAPTER 6 API Security」第 397 段(text/13-fm-introduction.txt:397,搜「brute force attacks」)。原文:「To capture failed login attempts allows for the detection of brute force attacks... A consistent, balanced logging strategy ensures that logs remain actionable」。 ↩

  28. 出处:「CHAPTER 6 API Security」第 403 段(text/13-fm-introduction.txt:403,搜「ELK」)。原文点名 ELK(Elasticsearch, Logstash, Kibana)与 Splunk;「By structuring logs for ingestion by a specialized tool like a SIEM」见同段。 ↩

  29. 出处:「CHAPTER 6 API Security」第 445 段(text/13-fm-introduction.txt:445,搜「Never log passwords」)。四条铁律:不记密码/key/PII、结构一致、锁定访问、定留存策略。 ↩