企业常遇 API 遭受大量攻击的紧急状况。API 如同住宅入口，需多重保护。本文实务拆解身份确认、权限管理、流量管控、资料检查、加密传输、错误隐藏以及监控警示等七项措施，协助中小企业从设计阶段纳入安全考量。
住宅入口需多重保护，API 同样需要
许多业主认同居家安全不可轻忽，却忽略自家网站 API 可能缺乏基本验证。API 是资料交换的关键通道，也是攻击者锁定的目标。根据 OWASP 报告，超过六成资料外洩与 API 弱点有关。只要网站涉及金流或会员功能，就必须重视 API 安全。
本文将说明常见威胁，並提供七项防护建议。若不熟悉 API，请先参阅相关整合指南。
API 为何容易成为目标
现代网站多依赖 API 传递资料，包括登入、订单及库存查询等。这导致商业逻辑直接暴露、原始资料无遮蔽、端点众多且自动化攻击成本低。
第一层：身份确认机制
身份确认用来验证请求来源，是安全基础。
API 金钥方式
为使用者核发金钥並置于标头中，切勿放在前端或网址参数。
OAuth 2.0 搭配 JWT
适合需要细部权限的场景，透过时效性权杖与编码资讯减少资料库查询。
实务建议
- 设定适当到期时间
- 实作权杖撤销功能
- 避免回传完整权杖
第二层：权限控管
确认使用者能执行的操作，避免物件层级授权缺失导致越权存取。
保护做法
- 检查特定资料存取权限
- 采用角色或属性控管模型
- 使用 UUID 取代可预测 ID
- 分离管理与一般 API
第三层：流量限制
防止暴力破解、阻断服务及资料爬取。
设定建议
- 依敏感度调整限制
- 回传 429 状态码
- 区分已验证与未验证请求
- 搭配 IP 与地区封锁
第四层：输入检查与过滤
绝不信任外部资料，以防注入攻击。
保护措施
- 定义型別与长度限制
- 使用白名单验证
- 执行输出编码
- 采用参数化查询
第五层：传输加密
强制使用 HTTPS，避免明文传输风险。
进阶做法
- 启用 HSTS
- 实作栏位级加密
- 使用凭证锁定
第六层：错误处理与隐藏资讯
避免回传敏感细节，改用通用讯息与代码。
不安全范例
{ "error": "User not found" }安全范例
{ "error": "认证失败", "code": "AUTH_001" }建议做法
- 仅回传通用讯息
- 详情记录于内部日志
- 关闭除错模式
第七层：日志监控与异常侦测
记录认证失败、异常模式及错误率，並设定即时警示。
应记录事件
- 认证失败请求
- 异常存取模式
- 权限提升尝试
警示条件
- 短时间多次失败即封锁
- 单一权杖过多资源存取
- 错误率异常上升
API 安全检核清单
- 要求有效身份验证
- 执行物件层级授权检查
- 设定合理流量限制
- 验证所有输入
- 全程使用 HTTPS
- 隐藏内部细节
- 完整记录日志
- 下架停用版本
结语：安全需持续演进
API 安全不是单次任务，而需多层防御与不断更新。建议在架构设计阶段即纳入保护措施。
