Next.js安全攻击面研究：从`__NEXT_DATA__`泄露到Server Actions权限边界

如果把 Next.js 当成一个真实目标来看，真正值得关心的问题通常不是“它有哪些功能”，而是：哪些能力最容易让边界变薄，哪些位置最值得优先投入时间。

如果把过去几年现代 Web 应用的技术栈做一个粗略观察，Next.js 大概会是最难绕开的名字之一。它已经不只是 React 生态里一个“很好用的框架”。在很多团队的实际工程里，它同时承载页面、路由、服务端渲染、缓存、接口，甚至一部分原本会被单独放到后端层的逻辑。

从开发角度看，这是一种非常自然的收敛：更多能力被放进同一个框架，交付速度更快，维护成本也更低。从安全研究的角度看，这种收敛同样值得注意。因为一旦页面渲染、服务端能力、缓存行为和资源处理被放进同一套抽象里，很多问题就不再表现为单点漏洞，而更像是边界被慢慢做薄之后产生的副作用。

这也是为什么 Next.js 值得单独拿出来看。这里真正有意思的，不只是某一个漏洞类型会不会出现，而是几个更基础的问题：

• 哪些数据原本只应该停留在服务端，最后却跟着页面一起出去了
• 哪些能力看上去只是性能优化，实际上会把服务器带入请求链
• 哪些缓存本来只是为了复用结果，最后却把用户上下文一起复用了
• 哪些新特性改善了开发体验，但没有改变它们本质上的安全边界

举几个很短的例子：

• 一个页面为了更快首屏渲染，把整份服务端对象直接带进了前端源码
• 一个图片优化入口本来只是帮前端拉资源，最后却让研究员开始关心服务端会替谁访问什么地址
• 一个用户态页面本来只是想被缓存得更快，最后却因为缓存边界不清晰，影响到了别的用户

这些例子表面上彼此无关，但它们背后往往是同一个问题：框架在帮开发者省去样板代码的同时，也把原本明确的边界收进了更抽象的一层。抽象做得越顺手，边界出错时往往就越不显眼。

所以这篇文章不会把 Next.js 写成一套使用说明，也不会把所有问题都塞回传统漏洞分类里。它更想回答的是另一个问题：如果把 Next.js 当成一个攻击面来读，研究员最应该优先看哪些位置，为什么这些位置反复值得看。

下面的结构也会尽量保持这个思路：不追求把概念铺满，而是优先回答“先看哪里更有效、为什么这里值得先看”。

一、先把 Next.js 看成一层收敛，而不只是一个前端框架

很多关于 Next.js 的讨论，仍然习惯先从 React 框架的角度出发。这当然没有问题，但如果你是从安全研究的角度进入，光把它理解成“前端框架的增强版”通常还不够。

更准确一点的说法可能是：Next.js 把原本分散在页面层、路由层、服务端渲染层、缓存层和一部分接口层的能力，收拢到了同一套开发抽象里。

从工程角度看，这种收拢很有吸引力。开发者不需要自己拼太多基础设施，就能获得：

• 路由
• 页面渲染
• 静态生成
• 服务端逻辑
• API 处理
• 缓存与资源优化

问题也恰好出在这里。当这些能力被放进同一个框架之后，安全问题就不再只是“某个输入点有没有过滤”，而更像是：不同层之间的边界，是不是仍然被清晰地保留了。

也正因为如此，Next.js 里经常出现的问题会呈现出一种很相似的气质：

• 页面源码里带出了本来只该停留在服务端的数据
• 框架为了帮前端拿资源，结果把服务器带进了请求链
• 页面和缓存的关系没有处理清楚，于是用户上下文被错误复用
• 新特性让状态变更更顺手，但没有让边界判断自动变正确

所以如果你想把 Next.js 看明白，一个很有帮助的起点往往不是去背功能，而是先接受这样一个判断：它的攻击面之所以有意思，不只是因为能力多，而是因为这些能力之间的边界经常被写进同一层抽象里。

二、为什么它值得被单独研究

从赏金或安全研究的角度看，一个技术栈值不值得深挖，通常取决于三件事：它是否足够常见、是否默认自带很多能力，以及开发者是否容易在“功能上写对、边界上写薄”。

Next.js 基本同时满足这三件事。

1. 它足够常见

研究一个技术栈，最怕的是花了很多时间，最后在真实目标里几乎碰不到。Next.js 没有这个问题。它已经非常广泛地出现在 SaaS、电商前台、内容站、营销站、管理后台和大量创业团队项目里。换句话说，你对 Next.js 攻击面的理解，很容易在不同目标上被反复复用。

2. 它默认自带很多能力

服务端渲染、静态生成、图片优化、API 路由、中间件、Server Actions——这些能力本身都没有问题，但它们意味着：框架默认就把很多值得研究的面暴露在了开发路径里。 能力越集中，研究员越应该留意这些能力之间有没有被错误地拼在一起。

3. 它很容易出现“功能没写错，边界却没写清”

很多 Next.js 问题并不是传统意义上的粗糙编码失误。更常见的情况反而是：

• 数据能跑通，但给前端给多了
• 页面能缓存，但缓存边界没有划清
• 资源能拉取，但拉取行为带入了服务端上下文
• 状态能变更，但权限判断或来源判断没有跟上抽象变化

这也是为什么它很适合研究。很多真正有价值的结果，不一定来自复杂利用链，而是来自对这些“默认很顺手的能力”再多追问一步：这里到底替开发者省掉了什么，以及它有没有顺手把边界也省掉。

三、一条更有效的起手路线

很多人拿到目标后，会先做一轮很机械的动作：扫目录、翻 JS、爆接口、抓请求。这些动作本身没有问题，但如果你已经确认目标是 Next.js，更高效的方式往往不是“先把所有东西翻一遍”，而是先找几个最能快速暴露边界处理方式的位置。

这也是下面这些部分的出发点。它们之所以值得优先看，不是因为每个位置都稳定产出漏洞，而是因为：这些位置经常最先告诉你，这个项目到底是怎么处理数据、缓存、服务端动作和资源代理的。 一旦这些事情被看清，后面的测试路径通常会顺很多。

四、从 __NEXT_DATA__ 开始，通常不会错

如果只保留一个最值得先看的位置，我通常会选 __NEXT_DATA__。原因并不复杂。很多 Next.js 页面需要先在服务端取数据，再把结果交给前端继续渲染。这个过程中，框架会把一部分页面状态和数据结构带回浏览器，而 __NEXT_DATA__ 往往就是最直接的观察窗口。

从研究的角度看，它的重要性不在于“这里一定有漏洞”，而在于：这里经常能最早暴露出边界是怎么被处理的。

它到底是什么

你可以把它理解成：

Next.js 往页面里塞的一坨 JSON，用来告诉前端“这个页面应该拿什么数据来渲染”。

当页面需要服务端先取数据，再把数据交给前端渲染时，这些内容很可能会以一种结构化的方式被塞进页面源码里，而 __NEXT_DATA__ 就经常是这个入口。

为什么这里特别容易出问题

因为很多开发者在服务端拿完数据之后，没有做细筛，直接把整包数据往前端丢。于是本来只该留在服务端的信息，也跟着一起出去了，比如：

• 用户信息
• 内部接口地址
• 第三方服务 key
• 调试字段
• feature flags
• 管理角色字段
• 某些令牌或临时配置

这类问题常常不是“利用链很复杂”，而是“信息泄露很直接”。

一个很简单的例子

比如某个页面源码里出现这样的内容：

{
  "pageProps": {
    "user": {
      "email": "admin@example.com",
      "role": "admin"
    },
    "apiBase": "http://internal-api:8080",
    "featureFlags": {
      "debugPanel": true
    }
  }
}

表面上看，这只是前端渲染数据。但从安全角度看，它已经给了你三类线索：

• 角色信息
• 内部接口地址
• 可能只该内部使用的调试开关

很多时候，真正有价值的不是这一段 JSON 本身，而是它把后面的攻击路径一起照亮了。

实战里怎么查

最简单的方法就是：

1. 打开页面源码
2. 搜 __NEXT_DATA__
3. 把里面的 JSON 单独拎出来看

这一步很多人会嫌笨，觉得不够高级。但实际上，这恰恰是很多高性价比结果的来源。

你重点看什么

你不是机械搜关键词，而是重点看这些方向：

• 有没有看起来像内部地址的东西
• 有没有明显不该给前端的配置项
• 有没有用户对象里带了过多字段
• 有没有某些“只有管理员才该看到”的开关
• 有没有调试信息和环境信息

为什么它值得优先测

因为它满足了一个很好的赏金特征：

• 检查成本低
• 命中率不低
• 一旦命中，通常能顺出更多线索

很多时候，一个看似不大的泄露点，会把后面的内部接口、权限模型、调试路径都带出来。所以不要轻视它。对 Next.js 来说，这经常是“最不像漏洞、但最值得看”的位置。

五、先分清：这个页面主要是谁在拼

很多人测站的时候不太区分渲染方式，结果就会出现一个问题：明明在测一个服务端逻辑，结果一直用前端思路在打；或者明明问题在浏览器侧，却老想着去碰接口。

为什么这个区分重要

因为不同渲染方式，决定了你该把注意力放在哪儿。如果页面是典型的服务端先吐数据，那你更应该关注：

• 页面源码里有没有多带数据
• 服务端在帮前端请求什么
• 中间有没有缓存层参与
• 服务端渲染时是不是混进了用户态信息

如果页面更多是浏览器端去拉接口，那你更应该关注：

• 前端 JS 里藏了什么接口路径
• 接口权限有没有问题
• 前端渲染链里有没有 DOM 注入点

一个很简单的判断思路

如果你刷新页面后，源码里已经能看到大部分内容，那它大概率更偏服务端先吐。如果源码里东西很少，但页面加载后内容才慢慢出来，那它更可能依赖浏览器端再去拿数据。这个判断不一定 100% 精准，但足够帮助你决定优先级。

通俗理解

你可以把这个问题理解成：这个页面的数据，到底是谁先拼好的？

• 如果是服务器先拼好给你，那你要怀疑服务端逻辑和数据注入
• 如果是浏览器自己拼，那你要多怀疑前端代码和 API 调用

这个判断会直接影响你后面的测试路径。一个很短的对比例子：

• 如果你在页面源码里已经看到了完整的用户资料卡片，那更像是服务端先把数据准备好了，这时候优先去看源码里有没有带出多余字段。
• 如果页面源码里几乎没有业务内容，但加载后前端又去请求 /api/profile，那这时候接口权限和前端调用关系通常更值得先看。

---

六、资源代理这类能力，通常值得多看一眼

Next.js 有些很方便的能力，本质上是：你给它一个资源地址，它替你去拿，然后再返回给你。 安全研究员看到这种模式，第一反应就应该是：这会不会变成服务端请求问题。

为什么这里危险

因为浏览器自己请求资源，和服务器替你请求资源，是两回事。一旦变成服务器去请求，攻击者就会开始思考：

• 它能不能被带去访问不该访问的位置
• 它会不会跟着跳转走
• 它能不能接触到内网资源
• 它有没有白名单，但白名单是不是配得很松

一个很典型的思路

比如某个站点支持这样的资源处理：

/_next/image?url=https://example.com/a.png&w=640&q=75

正常情况下，这只是图片优化。但如果来源校验过宽，或者能被跳转链带偏，研究员就会自然去想：

• 这个 url 能不能指向别的地方
• 它会不会跟 302 跳走
• 最后能不能摸到内网地址

这就是为什么类似能力值得优先看。它不是“功能看起来危险”，而是“设计上天然有被服务端代请求的属性”。

真实项目里为什么容易埋坑

开发团队往往为了方便，会希望：

• 支持更多图片来源
• 支持第三方 CDN
• 支持更多资源站点
• 支持自动重定向和兼容

一旦这些能力越开越宽，边界就容易松。所以你在测 Next.js 时，只要看到框架在“替用户取资源”，脑子里就要亮灯。不是说一定有问题，而是这种设计天然更值得安全研究员多看两眼。

你重点看什么

• 来源限制是不是过宽
• 是否允许跨域资源来源太多
• 是否存在可控跳转链
• 是否存在可被服务端拉取的远程地址
• 是否还有文件类型、SVG、内容处理等附加风险

这类点一旦出问题，通常不只是“拿一张图片”这么简单，它往往会往更高价值的方向扩展。

---

七、不要把 Server Actions 只当成新语法

很多人第一次看到 Server Actions，会把它当成一个开发体验优化。其实从安全视角看，它更像是：把一部分原来需要接口承载的服务端操作，换了一种形式暴露出来。 这就意味着一个关键点：原来接口该有的安全问题，它大概率也还是会有，只是表现形式不一样。

为什么它值得重点研究

因为它让“前端触发服务端动作”这件事变得更自然了。自然的另一面，就是开发者更容易忽略边界，比如：

• 这个动作到底该谁触发
• 来源校验做没做
• 权限校验是不是写在服务端真正入口上
• 某些情况下会不会被错误转发或错误重定向

一个简单例子

开发者原本可能会写一个 /api/update-profile 接口。后来换成 Server Actions 之后，前端看起来只是“点一下按钮”，后面却还是发生了真实的服务端状态变更。这时候研究员该问的不是“这语法新不新”，而是：

• 谁能触发它
• 触发条件是什么
• 服务端有没有独立做权限判断
• 请求来源和宿主信息有没有被错误信任

如果再说得更短一点，Server Actions 值得看的原因，往往不是因为它“新”，而是因为它让很多原本看起来像接口的事情，不再以传统接口的样子出现了。入口样子变了，边界问题通常并不会一起消失。

实战里为什么要盯紧它

因为这种新能力经常会出现两个问题：

1. 开发者习惯还没完全跟上
2. 生态周边的最佳实践还没完全沉淀

所以你会看到一些项目里，用法是新的，边界却还是旧的，结果就会出事。如果目标是较老版本、或者工程质量一般的项目，Server Actions 往往值得认真翻。

---

八、缓存问题经常比表面上更有研究价值

很多人一提缓存，第一反应是性能，不是漏洞。但在现代 Web 里，缓存配错了，经常能直接变成安全问题。 而 Next.js 又很依赖缓存思路，所以这一块尤其不能放过。

为什么缓存会出问题

因为缓存机制本质上做的是一件事：

这次请求的结果，下次能不能直接拿来复用。

问题就出在“复用边界”上。如果系统没分清：

• 哪些内容是公共的
• 哪些内容是用户私有的
• 哪些 header 会影响结果
• 哪些页面不该被共享

那就有可能出现：

• 本该只给一个用户的内容，被缓存给别人
• 本该受上下文影响的页面，被按公共资源缓存
• 某些可控输入进入缓存结果，影响后续访问者

一个最容易理解的例子

假设 /dashboard 页面本来应该是登录后用户自己的页面。但如果缓存层把它当成公共页面处理了，那么理论上就可能出现：

• 用户 A 访问后生成了一份缓存
• 用户 B 再访问时拿到的是这份缓存结果

你真正要测试的，不是“缓存有没有存在”，而是：缓存有没有把不该共享的东西共享出去。 同样地，如果一个站点的订单页、个人中心页、后台概览页在响应头上都表现得像公共资源，那你就不该再把它只当成性能问题，而应该开始怀疑：这里是不是把用户态页面缓存成了可复用页面。

为什么 Next.js 更值得看缓存

因为它本身就鼓励很多性能优化思路：

• 静态生成
• 增量更新
• 边缘缓存
• 页面复用
• 数据缓存

这些本身都没错，但只要“个性化内容”和“公共缓存”边界没划清，问题就会开始冒出来。

你重点看什么

• 个性化页面是否出现公共缓存特征
• 登录态内容是否被错误复用
• 某些 header 是否能影响缓存内容
• 页面是否存在不该共享的用户数据

缓存问题的魅力在于：它经常不是“一个点打穿”，而是“一个配置理解错了，整个行为都偏了”。 这种问题在赏金里很讨喜，因为如果你能证明影响范围，价值通常不低。

---

九、Source Map 依然是一个很好用的观察窗口

很多研究员会下意识觉得 Source Map 是“老问题”，好像不够高级。但我一直觉得，这类问题的价值不在于它是不是新，而在于：它能不能把原本看不清的前端逻辑，重新摊开给你看。

它的意义是什么

前端打包之后，代码经常已经压缩、混淆、拆块了。你直接读那些产物，很费劲，也很容易漏东西。一旦 Source Map 泄露，你看到的就不再是一团打包产物，而更接近开发者原本写出来的结构。这意味着什么？

• 更容易看清真实路由和调用关系
• 更容易发现隐藏接口
• 更容易发现调试逻辑
• 更容易看到命名语义
• 更容易顺着代码看权限和功能边界

一个很现实的价值

在没有 Source Map 的情况下，你可能只能看见一坨压缩后的变量名。有了 Source Map 之后，你更容易直接看到类似这样的语义：

• adminApi
• debugMode
• internalBaseUrl
• useServerAction

这会极大缩短你理解业务结构的时间。

为什么它在 Next.js 里有价值

因为 Next.js 项目通常前端逻辑不少，打包以后可读性下降很明显。一旦恢复结构，很多本来“只能猜”的东西，会直接变成“肉眼可读”。

一个很常见的变化是：原本你只能模糊地猜测“这里可能有个内部接口”，有了 Source Map 之后，这种猜测会迅速变成更具体的观察——接口名是什么、调用发生在哪里、它和哪个页面状态绑定在一起。对研究员来说，这种差别往往就已经足够大了。

你该怎么用这个线索

不要把它只当成“信息泄露”本身。更好的思路是：把它当成后续所有测试的放大镜。 它不是终点，而是让你后面更快找到高价值点的工具。

十、内容渲染链经常决定问题会不会浮出来

如果一个 Next.js 项目里存在这些功能：

• 博客发布
• 评论系统
• 富文本编辑
• Markdown 渲染
• 可视化内容编辑
• CMS 内容同步

那你几乎就应该立刻想到一件事：内容是怎么进 DOM 的。

为什么这里容易出问题

因为 React 默认是会帮你做一层转义的，这本来是好事。但很多业务为了显示格式化内容，会主动绕开这层保护，比如：

• 把 Markdown 转成 HTML 再渲染
• 允许后台内容带样式或标签
• 做富文本预览
• 引入第三方内容编辑器

一旦这条链里有一环做得不稳，XSS 风险就会出现。

一个简单例子

假设开发者把用户输入的 Markdown 转成 HTML 后，直接塞进页面。从功能角度看，这是“让内容显示得更漂亮”。从安全角度看，这就是在问：

• HTML 有没有被净化
• 哪些标签和属性被保留了
• 最终是以什么方式进入 DOM 的

这类问题不一定靠爆 payload 才能发现，很多时候看清渲染链本身，就已经很接近答案了。

你不要只盯着“输入框”

这类问题不一定只出在用户手填内容上，也可能出在：

• 后台导入的数据
• 第三方 CMS 同步内容
• 营销活动模板
• 帮助中心或公告系统

也就是说，越是“看起来像内容系统”的页面，越值得多看渲染链。

---

十一、工程侧线索有时比页面本身更诚实

Next.js 项目往往和 Node.js 生态深度绑定，所以它不仅有运行时攻击面，也会有很强的工程侧线索。比如：

• 包管理文件
• 配置文件
• 环境变量痕迹
• 私有包命名
• 构建与部署信息

为什么这部分重要

因为很多时候，你不是直接从“漏洞利用”里拿结果，而是从“工程侧泄露”里拿线索。这些线索可能不会立刻变成一个洞，但它们经常能告诉你：

• 项目依赖了什么
• 开发团队怎么组织工程
• 有没有私有包和内部体系
• 有没有暴露出进一步分析的入口

一个常见思路

如果你拿到了依赖、配置、构建痕迹，这些信息本身可能不算最终结果。但它们会帮你更快判断：

• 哪些组件值得深看
• 有没有版本相关的历史问题
• 有没有内部包、内部路径、内部命名体系

也就是说，它们不一定是漏洞本身，但常常是高价值漏洞的路标。

这类点的价值在哪

在高质量目标里，工程信息往往比表面页面更诚实。页面会伪装，构建产物和配置痕迹通常不会。所以你在看 Next.js 项目时，不要只盯着页面和接口，也要保留一个工程视角：这套东西是怎么被构建、被组织、被部署出来的。

再举一个很短的例子：假设你没有直接找到洞，但你从构建痕迹里看到了 internal-admin-sdk、staffOnlyApi、debugToolbar 这类命名。它们本身可能还不构成结果，但对研究员来说，这已经足够说明两件事：

• 这个项目大概率有内部能力和外部能力的分层
• 这些分层未必在每个入口都做对了隔离

很多时候，真正有价值的发现，不是从首页一路打进去，而是先从这些工程侧线索里闻到“哪里可能有内部边界”。

---

十二、如果要实战起手，可以按这个顺序看

如果你已经确认目标是 Next.js，但还不想一上来就把时间花在很散的枚举和试探上，一个更稳的起手方式通常是：先确认框架痕迹，再看页面怎么拿数据，再看那些最容易暴露边界问题的位置。

第一步：先确认它是不是 Next.js

很多时候这个并不难。

你可以从下面这些痕迹判断：

• 页面源码里有没有 __NEXT_DATA__
• 静态资源路径里有没有 _next/static
• 页面和资源结构是否符合 Next.js 常见特征

先确认技术栈，后面很多动作才有针对性。

第二步：先看源码，不要急着打

重点看：

• __NEXT_DATA__
• 页面里是否带了过多数据
• 是否能看出服务端渲染痕迹
• 是否能看出运行时配置

第三步：看 JS 和前端调用关系

重点不是“把 JS 全下载一遍就结束”，而是弄清楚：

• 页面会调哪些接口
• 哪些接口像内部管理接口
• 哪些功能只在前端做了限制
• 哪些内容渲染链看起来不太稳

第四步：看特殊特性

也就是 Next.js 特别值得看的那些东西：

• 图片优化
• Server Actions
• 中间件
• 缓存行为

第五步：最后再做更细的深挖

比如：

• 缓存问题验证
• 权限与身份边界验证
• 多角色、多账号对照测试
• 老版本特性的兼容问题

这个顺序的核心其实很简单：

先看清行为，再决定怎么测。

这样做不一定最炫，但在真实目标里通常更省时间。

十三、如果刚开始研究，可以先把这三个点练熟

如果你刚开始研究 Next.js，我建议你先别想一步到位全掌握。先把下面三个点练熟，性价比最高。

1. __NEXT_DATA__ 数据审计

因为这是最容易上手，也最能帮你建立 Next.js 安全感觉的点。你只要开始认真看这类数据结构，很快就会对“哪些东西本来不该被前端看到”形成直觉。

2. 内容渲染链

因为这个最容易帮助你把 React、前端渲染和 XSS 风险串起来。你会慢慢明白：不是 React 天生安全，而是 React 默认帮你挡了一层；一旦业务主动绕开，问题就回来了。

3. 缓存和页面复用逻辑

因为这个最能拉开你和普通测试者的差距。很多人只会盯着输入输出，而不会看缓存边界。但真正高价值的问题，往往就藏在“这个页面为什么会被复用给另一个人”这种地方。

十四、一个常见误区：不要把 Next.js 只当成“换皮 React”

这是一个很常见的误区。如果你只是把 Next.js 当成 React 的套壳，那你会天然忽略掉很多服务器侧和框架层问题。更准确的理解应该是：Next.js 是一个把前端体验、服务端能力、缓存机制和工程能力揉到一起的框架。 这意味着你测它的时候，也要用一个更立体的脑子：

• 既看前端
• 也看后端
• 既看页面
• 也看框架行为
• 既看接口
• 也看缓存与渲染路径

一旦你这么看，很多原来你以为“只是个前端项目”的目标，会突然变得很有意思。

---

十五、最后总结：真正值得研究的，通常不是功能本身，而是边界

如果只用一句话概括 Next.js 的安全研究重点，我更倾向于这样说：

不要急着把它拆成一串漏洞名词，先去看边界是怎么被处理的。

这个框架里反复出现问题的地方，往往都和边界有关：

• 服务端和前端的边界
• 公共数据和私有数据的边界
• 本地资源和远程资源的边界
• 用户请求和服务端代请求的边界
• 动态页面和缓存页面的边界

当这些边界被处理得足够清晰时，很多问题不会出现；但当这些边界被藏进抽象层、默认配置或者“图方便”的工程写法里时，问题就会开始以一种不太显眼的方式浮出来。

这也是为什么 Next.js 值得研究。

它并不是一个“天然更危险”的框架。更准确地说，它是一个很容易把复杂能力收敛到一起的框架，而只要能力收敛得足够多，研究员就有必要重新检查：哪些事情被简化了，哪些边界也在这个过程中一起被简化了。

所以如果你后面还会继续看 Next.js，一个很有用的习惯通常不是先问“今天我要找什么漏洞”，而是先问：

这里原本应该清晰分开的东西，现在是不是被框架替我揉到一起了？

很多真正有研究价值的发现，往往就是从这个问题开始的。

如果这篇文章能帮你建立起这个观察角度，那它的目的就已经达到了。

---

附：一个更适合实战的 Next.js 快速检查清单

基础识别

• 这个目标是不是 Next.js
• 页面里有没有 __NEXT_DATA__
• 静态资源里有没有 _next/static
• 是否能看出 SSR、静态生成或其他渲染痕迹

数据暴露

• 页面源码里有没有多余数据
• 用户对象有没有带过多字段
• 有没有内部地址、调试字段、配置项
• 有没有明显不该暴露给前端的运行信息

前端与渲染链

• 富文本/Markdown 是怎么渲染的
• 有没有主动绕开默认转义
• 有没有内容直接进 DOM 的链路
• 有没有高风险编辑器或模板场景

服务端代请求能力

• 框架是否替用户拉远程资源
• 图片、文件、远程内容处理边界是否过宽
• 是否存在值得深挖的来源校验问题

新特性与权限边界

• 是否使用 Server Actions
• 状态变更动作的边界是否明确
• 是否只做了前端限制，没有做服务端兜底

缓存行为

• 个性化页面是否存在公共缓存痕迹
• 缓存键是否合理
• 是否存在页面复用给错误用户的可能
• 是否有可控输入影响缓存结果

工程侧线索

• 是否有 Source Map 暴露
• 是否能看出依赖和构建结构
• 是否存在配置痕迹、包管理线索、环境信息线索

---

参考方向： Next.js 官方文档、真实项目源码、框架版本更新日志、公开安全研究文章、缓存与渲染相关案例分析。

安全研究是一场持续的攻防演练，不断学习和交流能让我们走得更远。你可以访问 云栈社区 获取更多前沿的技术解析和安全资讯，与广大开发者一起探讨交流。