尧图网页设计 
FckSignups 的 CORS 配置详解白名单如何保护你的 Worker【免费下载链接】FckSignupsA list of tools that are open-source, in-browser, and require no-signups!项目地址: https://gitcode.com/GitHub_Trending/fc/FckSignupsFckSignups又名 NoSignups是一个精选「无需注册即可使用」的开源浏览器工具清单它的提交后端是一个 Cloudflare Worker负责接收网页发来的工具提交、举报和建议并自动创建 GitHub issue。由于网站和 Worker 不在同一域名下浏览器的跨域限制让CORS 配置成为整个链路的关键一环。本文将拆解这套不到 20 行的白名单代码说明它如何做到「放行官方站点、挡住一切来路不明的请求」。为什么 Worker 需要 CORS 配置先用一个生活化的类比浏览器是「严格的门卫」它默认只允许「同一屋檐下」的网页互相访问数据同源策略。而 FckSignups 的前端页面和提交接口分属不同域名前端页面https://fcksignups.com提交接口https://fcksignups-submit.abdullahalkafajy.workers.dev当前端表单提交时代码会向 Worker 发起一个携带Content-Type: application/json的 POST 请求见 useModal.tsxconst response await fetch(submitURL, { method: POST, body: JSON.stringify(formProps), });这种「非简单请求」会触发浏览器的预检Preflight机制——浏览器先悄悄发一个OPTIONS请求询问 Worker「我能发 POST 吗」Worker 必须在响应头里给出明确许可浏览器才放行真正的请求。三个提交端点提交工具、举报工具、建议工具定义在 ModalConfigs.tsx 中全部指向同一个 Worker。白名单核心读一遍 corsHeaders 函数整个 CORS 逻辑集中在 utils.ts 的一个函数里const allowed [ https://nosignups.net, https://fcksignups.com, https://www.fcksignups.com, http://localhost:5173, http://localhost:4173, ]; return { Access-Control-Allow-Origin: allowed.includes(origin) ? origin : allowed[0], Access-Control-Allow-Methods: POST, OPTIONS, Access-Control-Allow-Headers: Content-Type, };这个白名单里有 5 个「受信任来源」各司其职白名单条目用途https://nosignups.net项目新域名生产https://fcksignups.com原正式域名生产https://www.fcksignups.com正式域名的 www 变体http://localhost:5173Vite 开发服务器默认端口http://localhost:4173Vite 预览模式preview默认端口一个巧妙的细节为什么不是直接返回*函数没有偷懒返回Access-Control-Allow-Origin: *而是回显请求方自己的 Origin——前提是它在白名单里。若 Origin 不在白名单则返回allowed[0]即nosignups.net。这时浏览器会做最后核对响应头里允许的 Origin 必须与发起请求的 Origin完全一致。第三方站点收到一个「允许 nosignups.net」的响应头与自己的身份对不上请求照样被浏览器拦截。也就是说回退值不是「漏洞」而是一道天然的安全兜底。预检请求如何被处理入口文件 worker.ts 的处理流程非常干净从请求头取出Origin收到OPTIONS预检请求 → 直接返回204 No Content CORS 响应头不执行任何业务逻辑非POST请求 → 返回404Worker 只接受写操作POST请求按路径分发到三个处理器路由处理器作用/submit-toolhandleReportTool.ts 风格创建工具提交 issue/report-toolhandleReportTool.ts创建工具举报 issue/suggest-toolhandleSuggestTool.ts创建工具建议 issue所有响应都带 CORS 头包括报错容易被忽略的一点utils.ts 中的jsonResponse工具函数在每一次响应包括 400 参数错误、404 路径错误、502 GitHub 接口失败都附带了 CORS 头return new Response(JSON.stringify(body), { status, status 状态码, headers: { Content-Type: application/json, ...corsHeaders(origin) }, }); 为什么这很重要如果只有成功响应带 CORS 头前端在失败时读取错误信息会被浏览器屏蔽用户只会看到一个「网络错误」的空白反馈。处处带头才能让前端优雅地展示「字段缺失」「链接非法」等具体提示校验逻辑见 handleSubmitTool.ts。白名单到底挡住了什么这套配置真正保护的是 Worker 背后的两样东西GitHub API 调用权限。Worker 通过环境变量持有GITHUB_TOKEN配置方式见 wrangler.toml 注释每次提交都会在项目仓库创建一条 issue。若任意第三方网站都能调用接口攻击者可批量灌入垃圾 issue污染仓库并消耗 API 配额。你的服务不被「借用」。没有白名单任何网页都能借用这个 Worker 的通道发请求你的带宽、日志和速率限制都会被消耗殆尽。一句话总结白名单把「谁能调用我」从「所有人」收敛到「我的官网 我的开发机」。本地开发把新域名加入白名单如果你在本地跑这个项目默认什么都不用改——Vite 的 5173/4173 端口已在名单内。只需git clone https://gitcode.com/GitHub_Trending/fc/FckSignups cd FckSignups/cloudflare-worker npm install npm run dev若你的前端跑在其他端口如 3000只需在 utils.ts 的allowed数组中追加http://localhost:3000重启wrangler dev即可生效。同理将来给 Worker 增加新的正式访问域名也是在这一处维护。给新手的安全清单写接口不要用*Access-Control-Allow-Origin: *只适合公开的只读 GET 接口任何会修改数据的 POST API都应使用白名单回显。✅只回显信任的 Origin像本文这样allowed.includes(origin) ? origin : 回退值是最小可用模式。✅显式声明方法与头Allow-Methods与Allow-Headers只写真正需要的这里只有POST, OPTIONS和Content-Type缩小攻击面。✅预检快速返回OPTIONS 直接 204不触碰业务逻辑。FckSignups 用几十行代码演示了一个可复制的模板把跨域信任边界写得和路由一样明确你的 Worker 就有了第一道、也是最便宜的一道防火墙。【免费下载链接】FckSignupsA list of tools that are open-source, in-browser, and require no-signups!项目地址: https://gitcode.com/GitHub_Trending/fc/FckSignups创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 FckSignups 的 CORS 配置详解：白名单如何保护你的 Worker
FckSignups 的 CORS 配置详解白名单如何保护你的 Worker【免费下载链接】FckSignupsA list of tools that are open-source, in-browser, and require no-signups!项目地址: https://gitcode.com/GitHub_Trending/fc/FckSignupsFckSignups又名 NoSignups是一个精选「无需注册即可使用」的开源浏览器工具清单它的提交后端是一个 Cloudflare Worker负责接收网页发来的工具提交、举报和建议并自动创建 GitHub issue。由于网站和 Worker 不在同一域名下浏览器的跨域限制让CORS 配置成为整个链路的关键一环。本文将拆解这套不到 20 行的白名单代码说明它如何做到「放行官方站点、挡住一切来路不明的请求」。为什么 Worker 需要 CORS 配置先用一个生活化的类比浏览器是「严格的门卫」它默认只允许「同一屋檐下」的网页互相访问数据同源策略。而 FckSignups 的前端页面和提交接口分属不同域名前端页面https://fcksignups.com提交接口https://fcksignups-submit.abdullahalkafajy.workers.dev当前端表单提交时代码会向 Worker 发起一个携带Content-Type: application/json的 POST 请求见 useModal.tsxconst response await fetch(submitURL, { method: POST, body: JSON.stringify(formProps), });这种「非简单请求」会触发浏览器的预检Preflight机制——浏览器先悄悄发一个OPTIONS请求询问 Worker「我能发 POST 吗」Worker 必须在响应头里给出明确许可浏览器才放行真正的请求。三个提交端点提交工具、举报工具、建议工具定义在 ModalConfigs.tsx 中全部指向同一个 Worker。白名单核心读一遍 corsHeaders 函数整个 CORS 逻辑集中在 utils.ts 的一个函数里const allowed [ https://nosignups.net, https://fcksignups.com, https://www.fcksignups.com, http://localhost:5173, http://localhost:4173, ]; return { Access-Control-Allow-Origin: allowed.includes(origin) ? origin : allowed[0], Access-Control-Allow-Methods: POST, OPTIONS, Access-Control-Allow-Headers: Content-Type, };这个白名单里有 5 个「受信任来源」各司其职白名单条目用途https://nosignups.net项目新域名生产https://fcksignups.com原正式域名生产https://www.fcksignups.com正式域名的 www 变体http://localhost:5173Vite 开发服务器默认端口http://localhost:4173Vite 预览模式preview默认端口一个巧妙的细节为什么不是直接返回*函数没有偷懒返回Access-Control-Allow-Origin: *而是回显请求方自己的 Origin——前提是它在白名单里。若 Origin 不在白名单则返回allowed[0]即nosignups.net。这时浏览器会做最后核对响应头里允许的 Origin 必须与发起请求的 Origin完全一致。第三方站点收到一个「允许 nosignups.net」的响应头与自己的身份对不上请求照样被浏览器拦截。也就是说回退值不是「漏洞」而是一道天然的安全兜底。预检请求如何被处理入口文件 worker.ts 的处理流程非常干净从请求头取出Origin收到OPTIONS预检请求 → 直接返回204 No Content CORS 响应头不执行任何业务逻辑非POST请求 → 返回404Worker 只接受写操作POST请求按路径分发到三个处理器路由处理器作用/submit-toolhandleReportTool.ts 风格创建工具提交 issue/report-toolhandleReportTool.ts创建工具举报 issue/suggest-toolhandleSuggestTool.ts创建工具建议 issue所有响应都带 CORS 头包括报错容易被忽略的一点utils.ts 中的jsonResponse工具函数在每一次响应包括 400 参数错误、404 路径错误、502 GitHub 接口失败都附带了 CORS 头return new Response(JSON.stringify(body), { status, status 状态码, headers: { Content-Type: application/json, ...corsHeaders(origin) }, }); 为什么这很重要如果只有成功响应带 CORS 头前端在失败时读取错误信息会被浏览器屏蔽用户只会看到一个「网络错误」的空白反馈。处处带头才能让前端优雅地展示「字段缺失」「链接非法」等具体提示校验逻辑见 handleSubmitTool.ts。白名单到底挡住了什么这套配置真正保护的是 Worker 背后的两样东西GitHub API 调用权限。Worker 通过环境变量持有GITHUB_TOKEN配置方式见 wrangler.toml 注释每次提交都会在项目仓库创建一条 issue。若任意第三方网站都能调用接口攻击者可批量灌入垃圾 issue污染仓库并消耗 API 配额。你的服务不被「借用」。没有白名单任何网页都能借用这个 Worker 的通道发请求你的带宽、日志和速率限制都会被消耗殆尽。一句话总结白名单把「谁能调用我」从「所有人」收敛到「我的官网 我的开发机」。本地开发把新域名加入白名单如果你在本地跑这个项目默认什么都不用改——Vite 的 5173/4173 端口已在名单内。只需git clone https://gitcode.com/GitHub_Trending/fc/FckSignups cd FckSignups/cloudflare-worker npm install npm run dev若你的前端跑在其他端口如 3000只需在 utils.ts 的allowed数组中追加http://localhost:3000重启wrangler dev即可生效。同理将来给 Worker 增加新的正式访问域名也是在这一处维护。给新手的安全清单写接口不要用*Access-Control-Allow-Origin: *只适合公开的只读 GET 接口任何会修改数据的 POST API都应使用白名单回显。✅只回显信任的 Origin像本文这样allowed.includes(origin) ? origin : 回退值是最小可用模式。✅显式声明方法与头Allow-Methods与Allow-Headers只写真正需要的这里只有POST, OPTIONS和Content-Type缩小攻击面。✅预检快速返回OPTIONS 直接 204不触碰业务逻辑。FckSignups 用几十行代码演示了一个可复制的模板把跨域信任边界写得和路由一样明确你的 Worker 就有了第一道、也是最便宜的一道防火墙。【免费下载链接】FckSignupsA list of tools that are open-source, in-browser, and require no-signups!项目地址: https://gitcode.com/GitHub_Trending/fc/FckSignups创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考