API网关是外部流量进入内部服务的统一入口，承担着路由转发、协议转换、认证授权和流量治理等职责。安全配置的目标不是单纯把请求转发正确，而是让网关成为内网服务前的一道有效防线。攻击者往往不会直接尝试穿透网关，而是先探测网关自身的默认端口、管理接口和错误响应。因此，安全加固必须覆盖传输链路、管理面、数据面请求策略以及日志输出等不同层面。下面分别从几个关键角度说明配置方法和容易遗漏的细节。
一、传输安全与管理接口收敛
传输层安全是网关安全的底线。对外提供HTTPS时，应至少启用TLS 1.2，有条件时直接使用TLS 1.3，同时禁用SSLv3、TLS 1.0和TLS 1.1。密码套件需要剔除RC4、3DES等弱算法，优先选择支持前向保密的ECDHE套件。证书有效期要纳入自动化监控，避免因为证书过期导致业务中断或客户端降级到不安全连接。在Nginx中可以通过ssl_protocols和ssl_ciphers指令收紧协议与套件，并开启HSTS响应头，强制浏览器后续直接访问HTTPS。
管理接口是比数据接口更危险的攻击面。以Kong为例，默认Admin API监听8001端口，如果未经限制直接绑定在公网网卡上，攻击者可以通过管理接口读取所有路由和上游信息，甚至创建新的路由。APISIX的Admin API虽然默认只监听127.0.0.1，但在容器化部署中仍需要确认网络模式。控制面与数据面应当分离，管理接口只允许本机或运维网段访问，并增加独立认证。下面是一段Nginx中限制管理接口访问的配置。
server {
listen 127.0.0.1:8001;
server_name localhost;
allow 127.0.0.1;
allow 10.0.0.0/8;
deny all;
location / {
proxy_pass http://127.0.0.1:8000;
}
}
除了网络层限制，管理接口本身还要启用身份认证和操作审计。Kong可以使用RBAC为不同运维角色分配最小权限，APISIX则建议在Admin API前增加一层认证代理。对普通数据面路由，不要开放TRACE等危险HTTP方法，可以在网关统一设置方法白名单，仅允许业务需要的GET、POST、PUT、DELETE等方法。隐藏Server头、X-Powered-By等版本信息，也能降低攻击者对网关指纹的识别概率。
二、认证与授权：不能只验签不验算法
JWT是网关层常用的无状态认证方案，但很多配置只做了签名校验，忽略了算法白名单和标准声明校验。攻击者可以利用alg为none的令牌直接绕过签名，或者在RS256与HS256之间进行混淆攻击。网关在验证JWT时必须显式指定允许的算法，例如只接受RS256，并根据令牌头中的kid或iss选择对应公钥。除了签名，还要校验exp过期时间、nbf生效时间、iss签发方和aud接收方，缺一不可。
网关层授权通常以粗粒度为主，例如按请求路径、HTTP方法和用户角色判断是否允许访问。后端服务仍需根据资源归属做细粒度对象级授权，防止横向越权。API Key在使用时应当生成足够长度的随机字符串，设置过期时间和轮换周期，避免硬编码在移动端或前端代码中。OAuth2接入时优先使用授权码模式，减少令牌在前端暴露的时间窗口。下面是一个APISIX中配置JWT认证插件的示例，实际部署时secret必须替换为独立密钥，不能使用默认值。
plugins:
jwt-auth:
algorithm: HS256
key: gateway-signing-key
secret: replace-with-secret
exp: 3600
base64_secret: false
所有未显式匹配到认证策略的路由都应默认拒绝。网关可以配置全局认证插件，任何新上线的路由如果没有挂载认证插件，流量直接返回401。不要让请求落到一个默认后端或兜底路由上，这种配置往往会成为绕过认证的入口。返回401或403时，响应体应保持统一格式，只说明认证失败，不要区分用户不存在、密码错误或令牌过期等细节，避免给攻击者提供有效信息。
三、请求防护：限流、大小与CORS
限流是抗暴力破解和基础DDoS的第一层手段。在网关上可以按客户端IP、用户ID、API路径三个维度配置限流规则。令牌桶算法允许一定程度的突发流量，漏桶算法则强制输出速度恒定，根据业务特点选择即可。分布式网关场景下，单机限流会失效，需要将计数存储放到Redis等共享组件中，保证全局限流效果一致。Nginx的limit_req_zone基于漏桶模型，配合burst和nodelay可以吸收短时突发。
请求体大小和超时时间同样不能被忽略。未限制client_max_body_size时，攻击者可以发送超大JSON或文件上传请求，耗尽后端内存或磁盘。根据业务实际需求设置2m或更小的限制即可。请求头数量和单个头大小也要配置，避免慢速头攻击占用连接资源。客户端头超时、客户端体超时、代理读取超时应当设置得足够短，防止慢连接拖垮网关工作进程。下面是一段Nginx限流与请求大小限制的配置。
http {
limit_req_zone $binary_remote_addr zone=api_limit:10m rate=100r/s;
limit_conn_zone $binary_remote_addr zone=conn_limit:10m;
client_max_body_size 2m;
client_body_timeout 10s;
client_header_timeout 10s;
server {
location /api/ {
limit_req zone=api_limit burst=200 nodelay;
limit_conn conn_limit 20;
proxy_pass http://backend;
proxy_read_timeout 30s;
proxy_send_timeout 30s;
}
}
}
CORS配置常常成为跨域攻击的突破口。允许来源写成*虽然方便调试，但如果同时允许携带凭证，就等于允许任意网站读取用户数据。生产环境必须根据业务域名显式列举允许的来源，网关根据请求头中的Origin动态判断是否放行。对允许的请求头和暴露响应头也要做最小化限制，预检请求的缓存时间不宜设置过长，否则策略调整后客户端仍可能使用旧的预检结果。统一在网关层处理CORS，可以避免后端重复配置导致规则冲突或绕过。
四、错误响应与日志审计脱敏
默认错误页和调试模式会向调用方泄露后端架构信息。网关应当拦截后端返回的错误响应，统一输出JSON格式，只包含状态码、错误码和请求ID。内部IP地址、上游服务地址、数据库错误、异常堆栈等信息一律不能出现在响应体中。Nginx可以通过server_tokens off隐藏版本号，使用proxy_hide_header去掉后端返回的Server、X-Powered-By等响应头。错误响应统一后，调用方只知道请求失败，但无法判断是网关自身错误还是后端服务异常。
审计日志是事后排查和攻击溯源的基础。访问日志应记录客户端真实IP、请求ID、用户ID、路由、HTTP方法、状态码、耗时和上游地址等必要字段。Authorization头、Cookie、请求体等敏感内容不能写入日志，否则一旦日志泄露，令牌和用户数据会批量暴露。日志建议使用结构化JSON格式，集中存储并设置严格的访问权限。下面是一段Nginx日志格式配置，只记录必要字段，避免记录认证头信息。
log_format main escape=json '{"time":"$time_iso8601","remote_addr":"$remote_addr",'
'"request_id":"$request_id","status":$status,'
'"body_bytes_sent":$body_bytes_sent,"request_time":$request_time,'
'"upstream_addr":"$upstream_addr"}';
access_log /var/log/nginx/access.log main;
安全事件告警需要和日志系统联动。连续出现401或403可能意味着暴力破解，同一用户短时间内触发大量限流或创建资源可能说明令牌被盗用。可以设置规则，例如每分钟同一IP出现超过50次401就触发告警，或者请求体大小持续接近阈值时通知管理员。日志和告警数据应接入SIEM系统，至少保留180天以便追溯。完成以上配置后，还应当定期用自动化扫描和人工渗透结合的方式验证，把每项检查固化为上线清单，每次新增路由或修改认证插件后重新执行一遍。
