企业官网建设流程全解析

前阵子做例行安全评估，凌晨两点的网关告警吓了我一跳：同一个GraphQL查询的耗时从80毫秒飙到17秒，从八层嵌套一路打穿三个底层微服务的数据库。攻击者其实没用什么花哨手法，只是发了一个构造精良的查询，就把我们自以为牢固的防线撕开一道口子。

那事之后我花了很长时间复盘：GraphQL加微服务的组合里，安全绝不是某个中间件能兜底的。入口的GraphQL层、中间的服务间通信、底层的数据库访问，每一层都有各自的薄弱点，攻击者往往会顺着一条看似无害的请求逐层渗透。这篇文章我想从攻击者的视角出发，把GraphQL和微服务架构下最常见的攻击路径、实操手法梳理一遍，再对应给出纵深防御的构建思路。内容偏实战，适合正在做API网关、写GraphQL resolver、维护微服务集群的工程师，或者像我一样负责安全评估的人参考。

1. 攻击者视角的GraphQL与微服务全景

1.1 攻击者眼里的目标轮廓是什么样的

接到一个评估任务时，我首先会把自己当成一个刚拿到目标入口的黑客。目标公司对外只暴露了一个网关入口，流量统一走GraphQL层，背后是几十个微服务。这个架构对防御方来说是“集中管理”，但对攻击者来说同样是个利好：所有路径都浓缩在一张schema地图里，只要攻破这一个入口，就能摸清整个系统的大部分结构。

攻击者画目标轮廓时最关心的三件事：

• GraphQL端点是否开启了introspection，能不能直接拉取完整的类型定义；
• 查询解析层有没有深度限制、复杂度限制，还是说只要语法合法就照单全收；
• 进入微服务调用链之后，服务之间是否验证身份，内部API是不是裸奔。

这三件事决定了一场攻击的“成本”。如果introspection开着，攻击者相当于拿到了系统所有接口的说明书；如果查询层不设防，一个简单的嵌套查询就能制造数据库压力；如果微服务之间没有鉴权，攻破边缘服务后就能横向移动，把数据拖个干净。

我常跟人说，攻击者的工作就是“顺着信任走”。GraphQL层信任了schema里的字段，攻击者就利用这些字段；网关信任了内网调用，攻击者就伪装成合法服务。搞清楚这些信任关系，就等于拿到了攻击路线图。

1.2 为什么GraphQL天生自带信息泄露体质

GraphQL和传统REST有个本质区别：REST的端点数量是有限的，每个端点返回什么数据是写死的；GraphQL则给客户端暴露了一套完整的类型系统，客户端可以按需组合查询字段。

这套设计的用户体验很好，但对安全来说却是双刃剑。

最大的问题叫“过度暴露”。你在设计schema时为了方便前端，可能会把一些字段也加进来，比如内部备注、数据库主键、审批人邮箱，这些字段在本意上并不是要暴露给所有用户的，但在GraphQL里它们天然属于全局类型的一部分。只要客户端知道字段名，就能直接查询。

还有一个要命的东西叫introspection（内省）。GraphQL规范里有一组隐藏查询，比如__schema、__type，它们的作用是让客户端自动发现schema。开发环境里用起来很方便，前端写完代码一刷新就能拿到类型提示。但很多团队把服务部署上线时忘了关掉这个功能，结果生产环境里任何人发一个introspection查询，就能把所有的类型、字段、枚举值、注释信息全部拉出来。

我实测过的项目里，通过introspection拿到内部对象模型的概率非常高。攻击者在浏览器控制台里发一个请求，马上能看到类似这样的返回：

{ "data": { "__schema": { "queryType": { "name": "Query" }, "types": [ { "name": "Order" }, { "name": "InternalNote" }, { "name": "AdminConfig" }, { "name": "Mutation" } ] } } }

看到InternalNote和AdminConfig这种名字，攻击者基本就知道该往哪个方向使力了。建议所有上生产环境的GraphQL服务，默认关掉introspection，只在内网测试环境开启，并且用鉴权保护这部分元数据接口。

1.3 微服务架构放大了哪些攻击面

过去单体应用时代，攻击面是单点的：一个应用、一个数据库、一层权限控制。微服务化之后，攻击面从“一个点”变成了“一张网”。

每个微服务都有自己的接口和数据库，服务之间还要互相调用。攻击者在攻破一个边缘服务后，往往会利用服务间的信任关系横向移动。这个现象在实际评估中太常见了。

比如我评估过某公司的订单系统架构：订单服务会调用用户服务查用户信息，用户服务会调用优惠券服务核算优惠，优惠券服务又依赖配置服务读取活动规则。攻击者只要想办法在某个GraphQL resolver里实现了任意文件读取，接下来就可以顺着这条调用链逐步探测内网其他服务。

微服务的另一个麻烦在于日志和链路追踪的割裂。单体应用出问题查日志比较简单，微服务架构下一个请求穿越了五六个服务，每个服务各记各的日志，如果没有traceId串联，出事儿后根本没法还原攻击者的完整操作路径。

很多团队的安全防护思路还停留在“把好入口关”的阶段，网关做了一堆防护，但服务间通信是靠内网信任裸奔的。可攻击者一旦进了内网，这种裸奔等于敞开了大门。所以微服务架构下的纵深防御，必须针对服务间通信单独设卡，不能只盯着最外面那道门。

2. GraphQL入口的常见攻击手法拆解

2.1 introspection查询：一次“目录枚举”的怪兽

提到GraphQL攻击，introspection是绕不开的第一站。在Web目录扫描里，攻击者会用一款工具去枚举路径，发现隐藏的接口；而在GraphQL世界里，introspection就是免费的目录枚举，甚至不用猜，服务端会主动把地图交出来。

实操中我经常这么干：拿到一个GraphQL端点，先用curl发一个最小查询：

curl -X POST https://target.example.com/graphql \ -H "Content-Type: application/json" \ -d '{"query":"{ __typename }"}'

如果端点支持GET请求，还会顺手试一下：

curl https://target.example.com/graphql?query=%7B__typename%7D

能返回{"data":{"__typename":"Query"}}就说明端点活着。紧接着直接上完整 introspection 查询，把整个schema拉下来：

query IntrospectionQuery { __schema { queryType { name } mutationType { name } subscriptionType { name } types { kind name description fields { name type { kind name ofType { kind name } } args { name type { kind name } } } } } }

拿到结果后，我还会保存成JSON文件，导入到本地工具里生成可视化的schema图。这样哪些对象之间有关联、哪些字段可以嵌套、哪些Mutation能改数据，一目了然。

我曾经在一个电商平台的GraphQL schema里看到一个叫userInfo的查询，参数是userId，返回字段里包含手机号、身份证号、订单记录。当时第一反应就是：这不就是天然的越权接口吗？后来用A用户的token去查B用户的数据，发现真的没有做任何对象级权限校验——一个userId变了，整个人的隐私数据全出来了。

防御端应对 introspection 的方法，一是生产环境关掉内省能力，二是在网关层拦截包含__schema或__type的查询，三是定期对schema做字段安全审计，把不该暴露的敏感字段收敛到内部服务。

2.2 深度与复杂度攻击：让服务器陷入计算泥潭

GraphQL查询是可以嵌套的。一个类型里可以包含另一个类型，另一个类型又包含下一个类型，嵌套的层数理论上没有上限。攻击者最爱的就是这种“递归式的查询地狱”。

举个例子，假设一个社交应用的schema是这样设计的：

type User { id: ID! name: String friends: [User!]! posts: [Post!]! } type Post { id: ID! title: String comments: [Comment!]! } type Comment { id: ID! content: String author: User! }

攻击者可以构造一个非常深的查询，一层套一层，让数据库执行大量的关联查询：

query DeepAttack { user(id: 1) { posts { comments { author { posts { comments { author { posts { comments { content } } } } } } } } } }

单看每一个字段都很正常，但嵌套在一起后，数据库和resolver会被迫执行海量子查询。如果没有深度限制，这个查询的复杂度是指数级增长的，一个小小的请求就能把后端拖垮。

另一种更阴险的攻击叫“星型查询”或“别名轰炸”。GraphQL允许客户端用别名发出多个相同字段的查询，比如：

query { a: user(id: 1) { name } b: user(id: 2) { name } c: user(id: 3) { name } # ... 重复几百次 }

攻击者在一个请求里塞入几百个别名，每个别名背后都是一次数据库查询。服务器依然会老老实实把每个字段都解析一遍，计算资源瞬间被占满。

我测试过某内部系统，用30个别名并发查询同一个接口，数据库连接池直接被打满，后面所有正常用户的请求全部超时。最棘手的是，这类请求在日志里看起来只是一个HTTP请求，很多WAF的“按请求数限流”策略完全没效果——因为请求量没变，变化的是单个请求内部的“重量”。

防御上需要两层手段：第一层是深度限制，比如规定嵌套不能超过5层或10层；第二层是复杂度计算，给每个字段设置一个成本分，当单次查询的总成本超过阈值就拒绝执行。这两件事必须在GraphQL解析层做，靠网关只数请求数是不够的。

2.3 批量查询与别名滥用：请求合并背后的放大倍数

上一节提到的别名轰炸本质上是“把一个请求的放大倍数拉满”。攻击者不需要发送成千上万个HTTP请求，只要构造一个包含大量别名的查询，就能实现类似分布式拒绝服务（DDoS）的效果。

我还见过一种更丝滑的组合：先通过introspection拿到schema里的列表字段，然后构造一条查询同时拉取多个资源：

query BatchAttack { user1: orderList(userId: 1) { id total } user2: orderList(userId: 2) { id total } user3: orderList(userId: 3) { id total } ... }

如果这个接口本身没有做权限隔离，这些查询还能顺带完成“批量越权”，一个请求就把一批用户的数据全拖走。

为什么很多防护体系对这种攻击特别乏力？因为防护策略通常基于“请求次数”或者“客户端IP”。别名轰炸把大量工作压缩进单个请求，攻击者只要伪造足够的别名数量，就能在限流阈值之下把后端资源榨干。

我在防御侧做过的有效方案有两个：

• 在GraphQL解析层限制单次查询的字段数量。比如规定一次查询最多200个字段，超过直接报错。
• 引入persisted queries（持久化查询）。客户端只能执行预先注册的查询，查询时传一个hash，服务端通过hash找到对应的查询体。这样攻击者再想自定义嵌套和别名，直接没门。

持久化查询的思路很直白：真正的前端代码里查询语句是固定的，提前把查询注册到白名单里，运行时只传hash。但这种方案对动态临时查询不友好，开发期或调试期会很痛苦。折中做法是：动态查询放宽但加严格限制，持久化查询完全白名单化，按需选择。

2.4 身份与授权绕过的漏洞环

GraphQL的授权问题比REST更容易出错，原因是GraphQL把数据和操作都抽象成了“字段”，但授权逻辑往往需要“按对象”来判断。

举个例子，REST接口GET /orders/123天然暗示了这是一次针对订单的操作；但GraphQL里你看到的可能是：

query { node(id: "123") { ... on Order { total items } } }

这里的id参数可以是任意对象的全局ID，如果resolver只检查了“用户是否登录”，却没有检查“这个订单是否属于当前用户”，那就是标准的不安全对象引用漏洞。

我在评估中发现的授权绕过路径通常有这么几种：

• 对象级授权缺失：接口校验了身份，但没校验“这个用户对这条数据有没有权限”。
• 字段级授权缺失：整个类型允许查询，但其中某些敏感字段（比如salary、phone）没有单独做权限判断。
• 变更操作（Mutation）授权缺失：查询做好了权限，但写操作忘了限权。
• 批量查询绕过限流：限流按“用户维度”做，但攻击者用多个账号或未登录的匿名token轮流打。

这里特别提醒一点：GraphQL的字段解析是嵌套的，resolver里容易出“局部权限”和“整体权限”不一致的情况。比如最外层对象检查了权限，但嵌套的子对象如果直接查询了，可能完全绕过外层检查。我处理这类问题时，通常会在所有涉及敏感字段的resolver里显式调用授权函数，而不是只在外层过滤器里做一次判断。

3. 微服务通信链路上的入侵路径

3.1 服务间调用的信任不对称

微服务架构里有个很常见的认知误区：以为只有网关暴露在公网，内网服务之间“没人看得到”，所以服务间调用不需要鉴权。但实际上，一旦攻击者通过GraphQL入口或其他方式打进内网，服务之间的接口就完全暴露了。

我在实际攻防演练里打到过这样一个场景：一个支付服务，接收来自订单服务的回调，回调URL是内网地址。这个接口没有做任何身份验证，只要请求里带上订单号和金额，就会执行支付流程的更新操作。攻击者在机房里随便找一台受感染的机器，往里发几个请求，就能把订单金额改掉。

服务间信任不对称的问题在于：外网的防护强度高，但内网的防护强度几乎为零。针对这种现象，最关键的是解决“谁有资格访问谁”的问题。

技术方案上，如果是新项目，建议直接上服务网格，比如双向TLS认证，每个服务工作负载都分配一个独立身份证，通信双方必须验证对端身份。如果暂时上不了服务网格，也可以在每个服务的配置中心里维护一份“允许调用方白名单”，在网关层或服务框架层校验来源身份。

3.2 上游数据注入与下游服务链污染

GraphQL经常会摄取外部数据，比如第三方回调、消息队列、对象存储事件。这些上游数据如果不可信，那么下游服务链就会跟着遭殃。

我印象很深的一个案例：某服务允许用户上传图片，然后通过后端处理服务生成缩略图。处理服务会解析图片元数据，再把结果写入数据库。攻击者上传了一张包含恶意XML的图片，后端解析器把它当成了XML实体注入的入口，直接读取了服务器上的敏感文件。

这类问题的本质是“信任数据源”而不是“信任输入内容”。在微服务链路里，每一个服务都可能成为攻击者的注入点，而不只是最外层的GraphQL。

防御措施强调三点：第一，所有服务间的数据传输都要有明确的格式约定和校验逻辑，比如JSON就严格按schema校验，对象存储事件只允许白名单字段；第二，不要在服务内部直接拼接查询语句或命令行参数，防止二次注入；第三，对上游数据做标记，比如区分“用户可控数据”和“系统可信数据”，服务处理时根据标记选择不同的信任策略。

3.3 错误响应与调试信息的信息泄露出口

攻击者特别喜欢看报错信息。一个写得潦草的GraphQL服务端，异常堆栈能直接把数据库表名、服务内部IP、甚至内网域名都吐出来。

我做过一次实验：构造一个明显非法的GraphQL查询，让后端解析器抛出异常，返回的信息里包含了类似这样的堆栈：

Error: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'internal_secret' in 'field list' at /app/vendor/package/src/QueryResolver.php:85 at /app/vendor/package/src/DatabaseAdapter.php:214

攻击者拿到这个堆栈，一下就知道后端是PHP、用的什么ORM、数据库类型是MySQL、表里有什么字段。配合上introspection信息，能进一步构造出SQL注入语句。

应对上，生产环境的GraphQL框架必须开启错误掩码（error masking），把异常信息里的堆栈和内部细节替换成通用的错误提示；同时把详细的诊断信息只输出到内部日志系统，日志系统里再通过traceId和requestId关联。

还要注意一个反直觉的点：GraphQL的错误响应里data和errors是分开的。有些字段解析失败时，服务端会把正确解析的部分data和错误信息一起返回。攻击者可以通过观察哪些字段解析成功、哪些失败，推断出后端的数据结构和权限规则。这种细颗粒度的探测在一定程度上有益于攻击者建模，防御时也要把这个信息量考虑进去。

4. 纵深防御构建：分层设卡与实操配置

4.1 网关入口：流量清洗与限流参数

纵深的第一个岗位是网关层。不要指望GraphQL服务自己防住所有恶意流量，网关应该挡掉最粗糙的扫描和探测。

我常用的一套组合是这样的：

• 反向代理层开启限流，按IP维度、按用户维度、按全局维度各设一层配额；
• 开启WAF规则，过滤掉明显的SQL注入、命令注入、路径穿越特征；
• 对GraphQL端点单独监控，统计查询频率和请求体大小基线。

Nginx侧的限流配置比较直接：

limit_req_zone $binary_remote_addr zone=graphql_per_ip:10m rate=10r/s; limit_req_zone $http_authorization zone=graphql_per_token:10m rate=20r/s; server { location /graphql { limit_req zone=graphql_per_ip burst=15 nodelay; limit_req zone=graphql_per_token burst=30 nodelay; limit_req_status 429; proxy_pass http://graphql_backend; proxy_set_header X-Real-IP $remote_addr; } }

注意上面的rate是请求速率，不是查询复杂度。正如前面说的，一个请求可能非常“重”，所以网关限流只能作为粗粒度防线，细粒度的查询成本控制交给GraphQL解析层。

网关层还应该做的另一件事是识别攻击工具的特征。很多黑客用现成的脚本扫描GraphQL端点，这些脚本的User-Agent、请求头顺序、HTTP版本都有规律。在网关层接一个基础的威胁情报或指纹库，能拦截掉早年间的自动扫描器。但别依赖它防住高级攻击者，人肉操作很难靠指纹拦。

4.2 GraphQL解析层：深度限制、复杂度成本与持久化查询

网关之下，GraphQL解析层是纵深防御的核心。这里需要做三件要命的事。

第一，深度限制。给嵌套深度设一个上限，通常在5到10之间。以我经验，正常的业务查询深度很少超过8层，超过这个深度基本就是攻击者在试探。

在JavaScript技术栈里，用graphql-depth-limit库非常方便：

const depthLimit = require('graphql-depth-limit'); const server = new ApolloServer({ typeDefs, resolvers, validationRules: [depthLimit(10)] });

第二，复杂度限制。比深度限制更进一步，它给每个字段赋予一个“成本”，然后统计整个查询的总成本。比如一个简单字段成本是1，一个需要联表查询的字段成本是5，一个返回列表的字段成本是10，嵌套关系再叠加。单次查询总成本超过2000就拒绝。

下面是一个示例，把成本计算绑定到schema字段上：

const { createComplexityLimitRule } = require('graphql-validation-complexity'); const rule = createComplexityLimitRule(2000, { scalarCost: 1, objectCost: 5, listFactor: 10, introspectionListFactor: 20 }); const server = new ApolloServer({ validationRules: [rule] });

第三，持久化查询。这是遏制别名轰炸的杀手锏。客户端预先注册好允许执行的查询语句，生产环境解析器只接受hash形式，不允许任意查询文本。

{ "queryHash": "a1b2c3d4e5f6...", "operationName": "GetUserProfile", "variables": { "userId": "123" } }

服务端收到请求后，用hash到白名单里找对应的查询体。找不到就直接拒绝。这样攻击者就算知道schema结构，也无法自己拼装任意查询。

针对introspection，生产环境可以直接在配置里关闭：

const server = new ApolloServer({ introspection: false });

如果业务上确实需要内省能力（比如内部工具调试），就单独部署一个加了鉴权的调试端点，和线上端点隔离。

4.3 服务间通信隔离：双向认证、最小权限网段与密钥管理

纵深防御走到内网这一层，核心策略从“防外部攻击”切换为“防横向移动”。

首先是服务间双向认证。目标是确保每一次服务调用都能验证双方身份，而不是仅仅验证“请求来自内网IP”。生产环境建议按服务网格的方式接入双向TLS。每个服务获得独立的工作负载身份，调用方和被调用方通过证书做双向校验。

配置上类似这样：

serviceEntry: hosts: - "payments.internal.svc" workloadIdentity: "spiffe://cluster/prod/payments-service" mtls: mode: STRICT

强制双向TLS的好处是，攻击者即使拿了一台边缘机器的权限，也无法直接冒充支付服务去调用其他服务，因为缺了对应的证书和身份。

其次是最小权限网段和网络策略。把不同类型的服务划分到不同的网络命名空间，只放行必要的端口和协议。比如支付服务只能被订单服务访问，数据库端口只对指定的应用服务开放。用Kubernetes的NetworkPolicy做这块很顺手。

apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: payment-allow-order-only spec: podSelector: matchLabels: app: payment ingress: - from: - podSelector: matchLabels: app: order ports: - port: 8080

最后是密钥管理。微服务架构下，密钥不应当写死在配置文件里或者镜像里面。统一的密钥管理系统，配合短时令牌，能显著降低私钥泄露的风险。每个服务启动时从密钥系统拉取自己的证书和数据库口令，进程退出令牌即失效。

4.4 观测与告警：异常行为画像和成本基线

纵深防御的最后一层是“看得见”。攻击者的行为再隐蔽，总会在某个地方留下痕迹，关键是你的监控体系能不能把这些信号捞出来。

我为GraphQL服务设计的观测体系包含四类信号：

• 查询成本分布：正常用户的查询成本呈钟形分布，如果某个token连续出现超高成本查询，立刻告警。
• 字段访问热度：统计每个字段被访问的频率，如果某个敏感字段在一夜之间访问量暴增，很可能是被批量拖数据。
• 错误类型分布：GraphQL错误有很多种，比如授权失败、校验失败、超时。某个客户端频繁触发“对象不存在”误差，说明在探测对象ID。
• 数据导出特征：某些查询明显是在拉取大列表数据，比如一下查询几千条记录，这种模式要单独标记。

告警不只是发一条通知，最好能自动带上上下文：哪个用户、哪个traceId、查询了什么字段、成本多大。这样安全工程师在处理告警时不用到处翻日志。

我用过一个很轻量的套路：在GraphQL执行完成之后，把查询解析结果的关键元数据，以结构化格式异步上报到监控系统：

afterResolver((context) => { metricsCollector.report({ traceId: context.traceId, userId: context.userId, operationName: context.operationName, queryHash: context.queryHash, complexityCost: context.complexityCost, depth: context.queryDepth, selectFields: Object.keys(context.selectedFields), latencyMs: context.latencyMs }); });

有了这些数据，后续做异常检测和攻击复盘都很方便。没有观测体系，很多攻击发生时你根本不知道被打过。

5. 实战中的坑与排查技法

5.1 限流参数设错引发的可用性事故

防护配置最怕“拍脑袋设参数”。我之前接过一次事故报告：上线了GraphQL深度限制功能，限制深度为3，结果前端大量列表查询嵌套超过3层，体验瞬间崩掉，用户反馈“页面加载不出数据”，最后紧急回滚。

这个坑的关键是：你没摸清正常业务查询的分布情况，盲目设了太严的参数。

正确做法是先观察，再收紧。上线防护功能前，先在测试环境跑一遍完整业务链路，把前端所有查询的深度、成本、别名数量统计出来，画个分布图。然后给限制条件留出至少20%到30%的余量。比如现有最大查询深度是6，可以设深度限制为8；现有最大查询成本是1500，可以设成本上限为2000。

如果怕误伤，还可以把超限行为从“直接拒绝”改成“降级”——对超限请求返回提示而不是直接报错，观察一段时间后再逐步收紧。GraphQL的validation规则支持自定义错误处理器，可以根据响应类型来决定是拒绝还是让请求继续但记录告警。

我的建议是，安全配置上线永远要通过灰度方式，先对一部分流量生效，确认没有误伤再全面开启。

5.2 权限模型上的绕权风险

我踩过最大的一次坑是在权限模型上：为某个用户类型加了一个新的敏感字段，代码里在对外暴露的field注解上加了@auth(role: "ADMIN")，以为这样安全了。结果上线后测试发现，未授权用户通过嵌套查询仍然能拿到这个字段。

原因很简单：我加注解的字段是一个嵌套子查询返回的字段，而子查询的resolver里并没有做权限校验。GraphQL的权限检查和字段解析是分开的概念，注解只影响“这个字段能不能被查询”，但如果外层通过其他路径绕过了这个字段本身，而是通过父节点把数据带出来了，注解就形同虚设。

解决这个问题的核心原则是：任何敏感字段必须在resolver内部做对象级授权检查，不能依赖全局的“字段级注解”。我后来在团队里定了一个规矩：涉及任何一个对象级权限判断，都要在resolver里显式调用授权函数，不允许只靠外层注解兜底。

const resolvers = { User: { salary: (parent, args, context) => { // 显式检查，当前用户是否有权查看该目标用户的薪资 assertCanViewSalary(context.currentUserId, parent.id); return parent.salary; } } };

如果嫌麻烦，起码要做到在网关层和解析层各做一层检查：网关通过权限策略文件判断“这个角色能不能查这个字段”，解析层再校验“这条数据属于当前用户”。

5.3 排查流程：从告警到修复复盘

最后分享一次从告警到完整修复的排查过程，给大家做个流程参考。

某天凌晨四点，监控系统发出告警：一个token连续五分钟内发出了几百条查询，查询成本持续在1500以上，远超基线。我立刻按这套步骤处理：

1. 立即拉取该token的查询日志，发现都是同一批哈希前缀的查询，来自同一个IP段，基本锁定是脚本行为。
2. 在入口网关临时封禁这个token和IP段，阻断攻击源，这一步最优先。
3. 把攻击期间完整的查询记录导出，包含查询体、字段、耗时、返回数据量，用于复盘。
4. 追踪这些查询在微服务链路上的调用，确认有没有触达敏感数据和写操作。
5. 检查数据库连接池和监控指标，确认服务没有被打穿。
6. 复现攻击路径，构造同样的查询，验证防御配置是否生效。结果发现深度限制生效了，但复杂度限制的参数有点宽松，攻击者构造的查询成本虽然在1500以上但没有超过2000上限。

整个复盘下来，我改了三个地方：复杂度上限从2000降到1200；新增对“单位时间内高成本查询数量”这个维度的告警；把所有查询日志里补上了userId和traceId的关联字段。

这套流程看起来简单，但很多团队在真实事故里会漏掉关键步骤，比如攻击结束就直接封IP完事，没做复盘，结果同一个漏洞换个IP又被打穿。防御体系的构建是一轮一轮磨出来的，不可能一次到位。

我个人在安全项目里最深的体会是：防御方的优势在于地对地导弹再多，不如把“发现-响应-修复”这条链路跑顺。GraphQL和微服务的安全性，本质上是每一层都别给对方留下过度信任的窗口。入口卡住schema、中间卡住服务身份、底层卡住敏感数据，再把观测做扎实，就算拦不住第一个动作，也来得及在第二个动作之前把门关上。