API 安全 — 认证、授权、加密、日志:把分层当第五条约束
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 落进集中日志。
- 认证 ≠ 授权:身份(你是谁)与范围(你能做什么)是两道独立的门,都得有人守。
- Base64 是编码不是加密——Basic 认证的安全感是错觉;没有 HTTPS,一切归零。
- Bearer 的核心是「持有即通行」:令牌必须短期 + 可刷新,泄露窗口压到最小。
- JWT 的价值是无状态:签名自带证据,验令牌不用查库;代价是载荷谁都能读、发了收不回。
- 权限设计三件套按序上:RBAC 扛组织结构 → ABAC 补具体条件 → scope 切任务粒度;最小够用是铁律。
- 通配 scope 是自杀开关(
[delete:*]级别的授权别给)。 - TLS 给三样:机密、真实、完整;银行级场景上 mTLS,但要先算证书运维的账。
- 日志四条铁律:不记秘密与 PII、结构一致、当敏感数据管、有留存策略。
- 安全活在这些层里:网关和中间件挡在前面,业务代码才不用每行都设防——这就是「分层」作为第五条约束的工程含义。
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」) |
Footnotes
-
出处:「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.」——注意:原文未给出统计来源。 ↩ -
出处:「CHAPTER 6 API Security」第 38 段(
text/13-fm-introduction.txt:38,搜「boarding a flight」)。原文四个环节一一对应:凭证换令牌如 ID 换登机牌;授权如登机牌限定登机口;加密如行李箱上锁;日志如监控摄像头。 ↩ -
出处:「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.」 ↩ -
出处:「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」。 ↩ -
出处:「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」。 ↩ -
出处:「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 段。 ↩ -
出处:「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」。 ↩ -
出处:「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.」 ↩ -
出处:「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.」 ↩ -
出处:「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」。 ↩ -
出处:「CHAPTER 6 API Security」第 221 段(
text/13-fm-introduction.txt:221,搜「eyJhbGci」)与第 227–266 段(头/载荷/签名三段结构)。样例中的exp1516249022 减iat1516239022 恰为 10000 秒。 ↩ -
出处:「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 段。 ↩ -
出处:「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」。 ↩ -
出处:「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 层,访客只读且够不到上层。 ↩ -
出处:「CHAPTER 6 API Security」第 300 段(
text/13-fm-introduction.txt:300,搜「administrative overhead」)。原文列了四利:权限收拢进角色、新人挂角色即可、可审计可合规、随组织扩展。 ↩ -
出处:「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.」 ↩ -
出处:「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」)。 ↩ -
出处:「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」。 ↩ -
出处:「CHAPTER 6 API Security」第 331 段(
text/13-fm-introduction.txt:331,搜「read:data」)与第 334 段(text/13-fm-introduction.txt:334,搜「OpenID Connect」)。 ↩ -
出处:「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 的令牌。 ↩ -
出处:「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.」 ↩ -
出处:「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]」。 ↩ -
出处:「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」。 ↩ -
出处:「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」。 ↩ -
出处:「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」。 ↩ -
出处:「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.」 ↩ -
出处:「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」。 ↩ -
出处:「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」见同段。 ↩ -
出处:「CHAPTER 6 API Security」第 445 段(
text/13-fm-introduction.txt:445,搜「Never log passwords」)。四条铁律:不记密码/key/PII、结构一致、锁定访问、定留存策略。 ↩