企业官网建设流程全解析

• 后端
• Web框架

@eggjs/security是 Egg 框架内置的 Web 安全插件，默认开启、零配置即可为应用提供 CSRF/CTOKEN 防跨站、安全重定向、XSS 过滤 Helper、Web 安全响应头与 HTTP 方法限制等一整套防护能力。本文以 plugins/security/README.zh-CN.md 为骨架，结合插件源码逐项拆解每一项防护的配置方式、底层实现原理与适用场景，帮助你理解"安全插件到底做了什么"，并能按业务需要精准地开启、关闭或裁剪某一项安全策略。

一、插件定位与快速上手

@eggjs/security位于仓库 plugins/security 目录，是 Egg 默认加载的安全插件，因此绝大多数场景下无需任何配置即可生效。在 Egg 应用中，你可以直接修改config/config.js（或 TypeScript 项目中的config/config.default.ts）来调整其行为：

exports.security = { xframe: { value: 'SAMEORIGIN', }, };

1.1 关闭某项安全防范

安全插件默认启用一套完整的防护集合。如果某项防护与你的业务冲突（例如需要被第三方以 iframe 嵌入页面而关闭xframe），只需将该配置项的enable设为false：

exports.security = { xframe: { enable: false, }, };

从源码 plugins/security/src/app/middleware/securities.ts 可以看出，插件启动时会把各项安全中间件 compose 成一个统一的security中间件；其中每一项若enable === false都会被直接跳过。同时源码也给出了一个兼容性提示：老版本可能使用config.security.xframe = false这种写法，当前版本会打印警告，推荐一律使用{ enable: false }的对象形式。

1.2 match 与 ignore：按路径精准控制

安全插件的每一项子配置都支持match与ignore两个路由匹配选项，取值可以是字符串（路径）、正则表达式、函数或它们的数组。例如只对/example路径开启 CSP：

exports.security = { csp: { match: '/example', // match: /^\/api/, // support regexp // match: ctx => ctx.path.startsWith('/api'), // support function // match: [ ctx => ctx.path.startsWith('/api'), /^\/foo$/, '/bar'], // support Array policy: { //... }, }, };

再如忽略/example路径上的xframe防护，以便合作商户能够嵌入本页面：

exports.security = { xframe: { ignore: '/example', // ignore: /^\/api/, // support regexp // ignore: ctx => ctx.path.startsWith('/api'), // support function // ignore: [ ctx => ctx.path.startsWith('/api'), /^\/foo$/, '/bar'], // support Array // ... }, };

注意：如果同时配置了match和ignore，以match为准，ignore会被忽略。这一逻辑在源码 plugins/security/src/app/middleware/securities.ts 中有明确实现：二者同时存在时输出 warning 并清空ignore。另外，顶层config.security.match/config.security.ignore已不推荐使用，源码会提示请在各项子配置上设置。

从实现上看，每项配置最终都会通过pathMatching(opt)（来自@eggjs/path-matching包）编译成匹配函数，注入到对应中间件选项中；中间件通过checkIfIgnore(opts, ctx)判断当前请求是否命中放行条件（见 plugins/security/src/lib/utils.ts）。

二、全局配置模型：默认开启哪些中间件

安全插件的全部配置项定义在 plugins/security/src/config/config.default.ts，使用 zod 做运行时校验并给出默认值。最核心的两个全局配置是：

• domainWhiteList：安全域名白名单，默认[]，用于安全重定向、shtml的 href/src 域名校验等场景；
• protocolWhiteList：协议白名单，默认[]，会与内置的http、https、file、data合并后用于surl校验；
• defaultMiddleware：默认启用的安全中间件列表，默认值为csrf, hsts, methodnoallow, noopen, nosniff, csp, xssProtection, xframe, dta，既可传逗号分隔的字符串也可传数组。

在 plugins/security/src/app/middleware/securities.ts 中，插件遍历defaultMiddleware，从lib/middlewares/index.ts（见 plugins/security/src/lib/middlewares/index.ts）按名称取出对应中间件工厂，逐个 compose 成一个总中间件。这意味着你可以在defaultMiddleware中整体增删中间件，也可以靠单项的enable开关控制。

值得说明的是：当前源码中hsts的enable默认值为false（config.default.ts），即Strict-Transport-Security 头默认不输出，需要 HTTPS 站点按需开启；而 README 中"hsts 默认开启"的描述相对旧版本而言已过时，本文统一以当前仓库源码为准。

三、CSRF 与 CTOKEN：跨站请求伪造的防范

3.1 基本用法：ctx.csrf

CSRF（跨站请求伪造）的防范思路是：在写请求中校验一个只有本站页面才能拿到的 token。插件通过ctx.csrf暴露 token，一般配合 POST 表单使用——页面渲染时将ctx.csrf作为表单隐藏域或 query string 渲染到页面上（key 为_csrf），提交表单时携带该 token 即可通过校验。

formData 上传时使用 csrf

<form method="POST" action="/upload?_csrf={{ ctx.csrf | safe }}" enctype="multipart/form-data"> title: <input name="title" /> file: <input name="file" type="file" /> <button type="submit">上传</button> </form>

从源码 plugins/security/src/app/extend/context.ts 可以看到，ctx.csrf并非直接返回 secret，而是基于csrf库用 secret 生成一个加了随机盐的 token——这是为了抵御 BREACH 类攻击，避免 token 与 secret 完全一致被暴力探测。

3.2 CTOKEN：Ajax 场景的防跨站

对于 Ajax 请求，页面拿不到隐藏域，插件提供了 ctoken（cookie token）方案：插件会把一个随机 secret 种到 cookie 中，前端发起 Ajax 时以ctoken为字段名携带该值即可。ctoken 的获取与校验由以下方法承担，文档明确约定这些是插件内部方法，使用者不要调用：

• ctx.ctoken：获取 ctoken 的逻辑（内部使用）；
• ctx.setCTOKEN()：设置 ctoken 的逻辑（内部使用）；
• ctx.assertCTOKEN()：ctoken 校验逻辑（内部使用）。

一个关键的域名设计是：ctx.setCTOKEN()会把 cookie 设置到主域名下，以支持主域名下不同子域名应用间的互相调用。例如在A.xx.com域种下 ctoken，cookie 会设置到xx.com域上，之后在B.xx.com域可以利用该 ctoken 发起请求；当 A 域通过 jsonp 请求 B 域时，B 域同样可以验证 ctoken。token 存在哪个 cookie、存什么字段等细节，都可以通过上述接口扩展定制。

3.3 csrf 配置项全解

完整的csrf配置项及默认值如下（与 config.default.ts 中 zod schema 完全对应）：

exports.security = { csrf: { type: 'ctoken', // 可以是 ctoken / referer / all / any，默认为 ctoken useSession: false, // 如果设为 true，secret 将存储在 session 中（需启用 session 插件，否则启动报错） ignoreJSON: false, // 如果设为 true，将忽略 json 请求（已标记为不安全，不建议使用） cookieName: 'csrfToken', // csrf 的 token 在 cookie 中存储的 key 名称（支持字符串数组，便于平滑迁移 cookie 名） sessionName: 'csrfToken', // csrf 的 token 在 session 中存储的 key 名称 headerName: 'x-csrf-token', // csrf token 在 header 中的名称 bodyName: '_csrf', // csrf token 在 body 中的名称（支持字符串数组） queryName: '_csrf', // csrf token 在 query 中的名称（支持字符串数组） rotateWhenInvalid: false, // csrf invalid 时刷新 token，用于同域名下多个业务 token 可能互相影响的情况 refererWhiteList: [], // referer 白名单（仅 type 为 referer 时生效） supportedRequests: [ // 支持的 url path pattern 和方法，按名单由上至下匹配 url path 正则 // 建议在自定义时配置 {path: /^\//, methods:['POST','PATCH','DELETE','PUT','CONNECT']} 为兜底规则 { path: /^\//, methods: ['POST', 'PATCH', 'DELETE', 'PUT', 'CONNECT'] }, ], // 以下为源码中可选的进阶配置： // cookieDomain: undefined, // 可为字符串或 (ctx) => string，默认以安全方式自动设置 // cookieOptions: { signed: false, httpOnly: false, overwrite: true }, }, };

其中supportedRequests是最灵活的开关：methods可以为空数组，如果把supportedRequests配置为[{ path: /^\//, methods: [] }]，则等效于关闭 csrf 防御。csrf 中间件的匹配流程见 plugins/security/src/lib/middlewares/csrf.ts：先检查 ignore，再确保 secret 存在，然后按supportedRequests逐条匹配path与method，命中才执行ctx.assertCsrf()。

3.4 四种校验类型与底层校验逻辑

type支持ctoken、referer、all、any四种取值，校验逻辑集中在 plugins/security/src/app/extend/context.ts 的assertCsrf()中：

• ctoken：校验请求携带的 token（从 query → body → header 依次查找）与 cookie/session 中的 secret 是否匹配，不通过则抛 403；
• referer：校验Referer/Origin头是否落在refererWhiteList与当前 host 构成的域名白名单内；
• all：ctoken 与 referer 两者都校验，任一失败即 403；
• any：两者任一通过即放行，都失败才 403。

token 的查找顺序为 query、body、header（对应queryName、bodyName、headerName）。此外，ensureCsrfSecret()负责在首次请求时生成并种下 secret（存 cookie 或 session），rotateCsrfSecret()可在用户登录等时机主动轮换 secret；当校验失败且配置了rotateWhenInvalid: true时也会自动轮换，避免同域多业务 token 相互影响。

四、安全重定向：safe redirect

开放重定向（Open Redirect）是一种常见的 Web 漏洞：攻击者构造跳转到钓鱼站点的链接诱导用户。安全插件覆盖了默认的ctx.redirect方法，让所有跳转都经过安全域名判断：

• ctx.redirect(url)：如果目标 url 不在白名单内则禁止跳转；
• ctx.unsafeRedirect(url)：绕过安全校验的原始跳转，不建议使用。

使用ctx.redirect前需要在应用配置中声明安全白名单（以.开头）：

exports.security = { domainWhiteList: ['.domain.com'], // 安全白名单，以.开头 };

特别要注意：如果没有配置domainWhiteList或数组为空，则默认对所有跳转请求放行（行为等同于ctx.unsafeRedirect(url)）；同时域名和 url 检查不区分大小写。也就是说，"白名单为空即放行"是为了兼容旧应用，一旦你配置了白名单，安全检查即生效。

重定向的具体实现见 plugins/security/src/app/extend/response.ts：

1. 以/开头的相对路径视为站内跳转，直接放行（但//开头会被归一化为/，/\形式会走后续检查，防止协议相对跳转绕过）；
2. 非相对路径解析 URL，仅允许http:/https:协议；
3. 若配置了非空domainWhiteList，则通过ctx.isSafeDomain()校验 hostname，生产环境下不通过会记录告警并重定向到/，非生产环境直接抛 500 便于暴露问题。

ctx.isSafeDomain(domain)

ctx.isSafeDomain(domain)用于判断某个域名是否为安全域名（安全域名即上面domainWhiteList中配置的域名）。源码实现位于 plugins/security/src/lib/utils.ts：比较时统一转小写、忽略大小写；白名单项若包含*则按通配符匹配（如*.domain.com）；普通项自动补.前缀后做后缀匹配，且刻意避免wwweggjs.com误匹配eggjs.com这类前缀相似域名。

五、JSONP 接口防护

JSONP 依赖在页面中动态插入<script>执行回调，若回调函数名可控，极易造成 XSS。Egg 的 jsonp 防护在 context 层实现（使用jsonp-body模块），防御内容包括：

• callback 函数名长度限制：最长 50 个字符（limit可配置）；
• callback 函数名字符白名单：只允许[、]、字母、数字、_、$、.，防止一般 XSS、UTF-7 XSS 等攻击；
• 默认的 callback 参数名为_callback，可改名。

六、安全 Helper 全家桶：XSS 过滤与命令注入防护

插件在ctx.helper上注册了一组安全过滤函数，统一声明在 plugins/security/src/lib/helper/index.ts。它们解决不同场景下的注入问题，注意：并不是任何时候都要用最"重"的过滤，按输出位置选择最合适的 helper 才是最佳实践。

6.1.escape()：HTML 实体转义

对字符串做 HTML 实体转义，是安全性最高、最基础的 XSS 过滤方式：

const str = '><script>alert("abc") </script><'; console.log(ctx.helper.escape(str)); // => &gt;&lt;script&gt;alert(&quot;abc&quot;) &lt;/script&gt;&lt;

在 nunjucks 等模板引擎中默认会做 escape，无需显式调用；只有在你手工拼接 HTML 字符串时才需要显式使用。

6.2.surl()：URL 过滤

用于在 HTML 标签中需要解析 URL 的地方（如<a href="">、<img src="">），其他地方不允许使用。模板中要输出的变量应包裹helper.surl($value)：

不使用 surl：

<a href="$value" />

output:

<a href="http://www.domain.com<script>" />

使用 surl：

<a href="helper.surl($value)" />

output:

<a href="http://www.domain.com&lt;script&gt;" />

特别需要注意：在需要解析 url 的地方，surl 外面一定要加上双引号，否则"不会被当作属性分隔符处理，反而会导致 XSS 漏洞。

从源码 plugins/security/src/lib/helper/surl.ts 看，surl 会先校验协议：相对路径放行，绝对路径的协议必须命中白名单（默认http、https、file、data加自定义protocolWhiteList），非白名单协议直接返回空字符串；随后把"、'、<、>转义为 HTML 实体。

6.3.sjs()：JavaScript 字符串转义

用于在 JS（包括onload等事件属性）中输出变量。它会对变量中的所有非白名单字符做 JAVASCRIPT ENCODE，转义为\x形式，防止 XSS 攻击，也确保输出在 JS 中语义正确：

const foo = '"hello"'; // 未使用 sjs console.log(`var foo = "${foo}";`); // => var foo = ""hello""; // 使用 sjs console.log(`var foo = "${this.helper.sjs(foo)}";`); // => var foo = "\\x22hello\\x22";

6.4.shtml()：富文本过滤

当需要把包含 HTML 的富文本（如用户输入的帖子内容）直接输出到模板中时，使用shtml。它允许输出白名单内的 HTML tag，同时执行 XSS 过滤，剔除非法脚本：

// js const value = `<a href="http://www.domain.com">google</a><script>evilcode…</script>`; // 模板 <html> <body>${helper.shtml($value)}</body> </html>; // => <a href="http://www.domain.com">google</a>&lt;script&gt;evilcode…&lt;/script&gt;

这是一个非常复杂的安全处理过程，对服务器处理性能有一定影响，如果不是输出 HTML，请勿使用。shtml 基于xss模块，在其默认白名单规则基础上增加了针对域名的过滤（源码见 plugins/security/src/lib/helper/shtml.ts）：

• 默认规则：仅放行白名单内的 tag 与属性（如<a>标签默认只保留href、title等有限属性）；
• 自定义过滤项：通过whiteList覆盖，例如只支持a标签、且除title外其他属性全部过滤：

whiteList: { a: ['title']; }

• 属性级自定义：可通过onTagAttr(tag, name, value, isWhiteAttr)回调定制某个 tag 属性的处理逻辑，插件内置的域名校验会作为兜底逻辑保留；
• 域名过滤：href/src属性会校验其 hostname 是否在config.security.domainWhiteList中，不在则属性被清空。config.helper.shtml.domainWhiteList已过时，请使用config.security.domainWhiteList代替。

注意 shtml 的白名单是"严格"的：除了过滤 XSS 风险字符串外，不在默认规则中的 tag 和 attr 都会被过滤掉。例如<html></html>标签不在白名单中，输出为空；常见的data-xx自定义属性也会被过滤。因此：

shtml 的适用场景一般是来自用户的富文本输入（论坛、评论系统等），切忌滥用。如果业务本身不支持 HTML 内容输入，直接使用escape即可，既快又安全。

6.5.spath()：路径安全校验

把输入字符串用作 path 路径时，必须用spath做安全检验；路径不合法时返回null。不合法路径包括：

• 使用..的相对路径（目录穿越）；
• 使用/开头的绝对路径；
• 以上试图通过 url encode 绕过校验的结果字符串（内部会先做decodeURIComponent再判断，见 plugins/security/src/lib/utils.ts 的isSafePath）。

const foo = '/usr/local/bin'; console.log(this.helper.spath(foo2)); // => null

6.6.sjson()：JSON 输出转义

在 JS 中输出 JSON 时若未转义，易被利用为 XSS 漏洞。sjson会对 JSON 做编码：遍历 JSON 的 key，将 value 中所有非白名单字符转义为\x形式，同时保持 JSON 结构不变。若需要在模板中输出一个 JSON 字符串给 JS 应用使用，请使用${this.helper.sjson(变量名)}进行转义：

<script>window.locals = ${this.helper.sjson(locals)};</script>

该处理过程较复杂、性能损耗较大，应尽量避免使用——能提前序列化并单独转义的部分，尽量在业务层处理。

6.7.cliFilter()：远程命令执行防护

远程命令执行（RCE）漏洞的典型场景是：用户通过浏览器提交的参数被直接拼进系统命令，服务器端未做过滤，攻击者可借此执行任意命令、入侵服务器。如果用户可控变量是命令中的参数，直接用cliFilter过滤：

修复前：

cp.exec('bash /home/admin/ali-knowledge-graph-backend/initrun.sh ' + port);

修复后：

cp.exec('bash /home/admin/ali-knowledge-graph-backend/initrun.sh ' + this.helper.cliFilter(port));

如果业务需要在参数中添加白名单之外的字符，可以将用户输入按该字符分割，并对每一段分别调用过滤函数。如果用户可控变量是命令本身（而非参数），则应与开发协商修改功能或直接下线该功能——此时任何过滤都无法保证安全。

6.8.escapeShellArg()：POSIX shell 参数转义

对单个 shell 参数做 POSIX 转义：给字符串增加一对单引号，并对已存在的单引号做引用/转码处理，从而安全地把它拼接进 shell 命令字符串：

const ip = '127.0.0.1 && cat /etc/passwd'; const cmd = 'ping -c 1 ' + this.helper.escapeShellArg(ip); console.log(cmd); //ping -c 1 '127.0.0.1 && cat /etc/passwd'

如果可以，应优先使用child_process.execFile()或child_process.spawn()的参数数组形式，彻底避免字符串拼接。这个 helper 只用于 POSIX shell 命令字符串里的单个参数，不适用于 Windowscmd.exe或 PowerShell 转义。

6.9.escapeShellCmd()：命令行整体转义

从输入的命令行中直接删除危险字符：#&;`|*?~<>^()[]{}$;'", 0x0A 和 0xFF：

const ip = '127.0.0.1 && cat /etc/passwd'; const cmd = 'ping -c 1 ' + this.helper.escapeShellCmd(ip); console.log(cmd); //ping -c 1 127.0.0.1 cat /etc/passwd

可以看到&&、分号等分隔符被剔除，命令被"打散"成无法注入的形式。相比escapeShellArg，它更激进但可能改变参数含义，适用于需要保留整条命令字符串的场景。

七、Web 安全响应头：由中间件批量注入

插件以中间件形式（位于 plugins/security/src/lib/middlewares）在响应阶段统一注入安全响应头。下面按 README 顺序逐一说明，并标注当前源码中的默认值与配置入口。

7.1 HSTS：Strict-Transport-Security

HSTS 强制浏览器只通过 HTTPS 访问本站。按当前源码默认enable: false，需要 HTTPS 站点手动开启（README 中"默认开启"的描述对应旧版本）；如果是纯 HTTP 站点则务必保持关闭。

• maxAge：默认一年，即365 * 24 * 3600；
• includeSubdomains：默认false，设为true时规则同样适用于所有子域名。

实现见 plugins/security/src/lib/middlewares/hsts.ts，响应头格式为strict-transport-security: max-age=<maxAge>[; includeSubdomains]。

7.2 CSP：Content-Security-Policy

CSP 默认关闭（enable: false）。需要开启时，必须和安全工程师共同确定策略，主要配置项为policy（策略对象，key 为指令名，value 可为字符串、字符串数组或布尔值）。源码还支持reportOnly（仅上报不拦截）与supportIE（IE 兼容）两个可选开关。此外，插件在 context 上提供了ctx.nonce（随机 16 位字符串），可用于 CSP 的 nonce 机制放行内联脚本（见 plugins/security/src/app/extend/context.ts）。

exports.security = { csp: { enable: true, policy: { 'default-src': "'self'", // 'img-src': ['*', 'data:'], }, }, };

7.3 X-Download-Options: noopen

默认开启，禁用 IE 下载框中的 "Open" 按钮，防止 IE 下下载文件默认被打开而触发 XSS。对应中间件 plugins/security/src/lib/middlewares/noopen.ts。

7.4 X-Content-Type-Options: nosniff

默认开启，禁用 IE8 的 MIME 自动嗅探功能。例如响应声明text/plain却可能被当成text/html渲染——尤其当本站点服务内容未必可信时，nosniff 可以防止这类降级攻击。对应中间件 plugins/security/src/lib/middlewares/nosniff.ts。

7.5 X-Frame-Options

默认值SAMEORIGIN：只允许同源页面把本页面当作 iframe 嵌入。value可配置为DENY、SAMEORIGIN或ALLOW-FROM https://example.com。实现见 plugins/security/src/lib/middlewares/xframe.ts。

7.6 X-XSS-Protection

默认开启，value默认为'1; mode=block'（即 README 中close默认false所对应的输出）。开启后浏览器会在检测到反射型 XSS 时拦截页面渲染。

7.7 补充：referrerPolicy 与 dta

除 README 列出的响应头外，当前源码还默认启用了两个值得了解的中间件：

• referrerPolicy：默认enable: false，输出Referrer-Policy头，默认值no-referrer-when-downgrade，用于控制浏览器在跳转时携带多少来源信息，保护隐私与防信息泄露；
• dta：默认enable: true，自动拦截目录穿越（Directory Traversal Attack）请求，基于isSafePath判断路径是否包含..穿越或编码绕过（见 plugins/security/src/lib/middlewares/dta.ts）。

八、其他防护与扩展能力

8.1 请求方法限制

插件默认禁止TRACE与TRACK两种 HTTP 方法（对应 OWASP 的 Cross Site Tracing 攻击），命中时直接返回 405。实现见 plugins/security/src/lib/middlewares/methodnoallow.ts：以 Node 内置METHODS为基准，剔除TRACE/TRACK后构建安全方法映射表。

8.2 crossdomain.xml 与 robots.txt

crossdomain.xml、robots.txt默认都不由本插件输出，业务系统可自行添加；如涉及敏感信息，需要咨询项目安全工程师确认策略。

8.3 SSRF 防护与 safeCurl（源码扩展）

当前源码在配置模型中新增了ssrf配置（config.default.ts），用于服务端请求外发时的 SSRF 防护，支持：

• ipBlackList：IP 黑名单（支持精确 IP 或 CIDR 网段，如'127.0.0.0/8'）；
• ipExceptionList：从黑名单中豁免的 IP；
• hostnameExceptionList：豁免的 hostname 列表；
• checkAddress：自定义校验函数(address, family, hostname) => boolean，优先级最高。

黑名单/豁免逻辑在 plugins/security/src/lib/utils.ts 的preprocessConfig中预编译为checkAddress：先查 hostname 豁免，再查 IP 豁免，命中黑名单即拒绝，默认放行。与之配套的是 context 与 application 上的safeCurl()方法（见 plugins/security/src/app/extend/context.ts 及 plugins/security/src/lib/extend/safe_curl.ts），对应用外发请求做安全包装。

九、实践建议与总结

1. 默认值即安全基线：csrf、xframe、nosniff、noopen、xssProtection、dta、methodnoallow默认开启，不建议整体关闭；hsts、csp、referrerPolicy按站点协议与业务需求显式开启。
2. 按路径精细控制：善用各项子配置的match/ignore（字符串、正则、函数、数组），例如仅对支付/登录接口严格校验 CSRF，对第三方嵌入页面放行xframe。
3. 输出场景决定过滤方式：模板变量默认逃逸；拼接 HTML 用escape；URL 属性用带双引号的surl；JS 内输出用sjs；富文本才考虑shtml（注意其白名单严格性与性能开销）；文件路径用spath；命令参数用cliFilter/escapeShellArg/escapeShellCmd，并优先使用execFile/spawn的参数数组形式。
4. 安全重定向必须配置白名单：domainWhiteList为空时ctx.redirect会退化为放行所有外链，务必按['.yourdomain.com']的格式显式声明。
5. 关注版本差异：README 中的部分描述（如 hsts 默认开启）与当前源码默认值存在出入，实际行为以 plugins/security/src/config/config.default.ts 的 zod schema 为准。

@eggjs/security的价值在于"开箱即用的安全基线 + 精细可裁剪的配置面"：它把 CSRF/CTOKEN、安全重定向、XSS 过滤、安全响应头、方法限制、目录穿越与 SSRF 防护等常见 Web 威胁统一收敛到一套配置模型与一组 Helper 中。理解每个配置项的默认值与底层实现，就能在保证安全的前提下，为业务定制最合适的防护策略。

延伸阅读

• 插件主文档：plugins/security/README.zh-CN.md
• 默认配置与类型定义：plugins/security/src/config/config.default.ts
• 中间件组装逻辑：plugins/security/src/app/middleware/securities.ts
• 安全中间件实现目录：plugins/security/src/lib/middlewares
• 安全 Helper 实现目录：plugins/security/src/lib/helper
• context 扩展（csrf/ctoken/非ce）：plugins/security/src/app/extend/context.ts
• 安全重定向实现：plugins/security/src/app/extend/response.ts

• 后端
• Web框架