Hister安全设计解析CSRF、CSP与敏感内容日志脱敏【免费下载链接】histerYour own search engine项目地址: https://gitcode.com/GitHub_Trending/hi/histerHister 是一个自托管的私有搜索引擎Your own search engine它把网页存档、全文检索和语义搜索收进你自己的服务器。正因为数据高度私密Hister 在 Web 服务层做了三层经典安全防护CSRF 防跨站伪造请求、基于 Nonce 的 CSP 防脚本注入以及刻意少记的访问日志脱敏设计。本文带你用最短的时间看懂这三道防线。三道防线总览Hister 的服务端代码集中在 server/ 目录安全设计主要分布在三个文件里防线作用源码位置CSRF Token 校验阻止第三方网页伪造你的操作server/server.go#L340-L393Nonce 制 CSP阻止外部脚本注入与执行server/endpoints.go#L166-L178访问日志脱敏敏感内容不落盘到日志server/server.go#L396-L403一键看懂CSRF 是怎么被拦下的CSRF跨站请求伪造的典型场景是你已登录 Hister然后点开了一个恶意网站它偷偷以你的身份调用 Hister 的删除、写入接口。Hister 在withCSRF中间件server/server.go#L340-L393里是这样防的默认拒绝写操作只有GET和HEAD是安全请求其余方法必须携带 CSRF Token双重通道提交Token 可以从表单字段或X-CSRF-Token请求头提交服务端与 Session 中存储的 Token 逐一比对不匹配直接返回403 Forbidden每次响应都轮换 Token校验通过后服务端生成新 Token通过X-CSRF-Token响应头返回给前端旧 Token 立即失效攻击者截获的过期 Token毫无用处来源白名单来自本机命令行Origin: hister://、同源请求Sec-Fetch-Site: same-origin和浏览器扩展的请求走各自通道其中扩展来源如moz-extension://由浏览器控制网页无法伪造注释里写得很明白。配合 Cookie 层的加固——server/session.go#L39-L56 中 Session Cookie 设置了HttpOnlyJS 读不到、SameSiteLax跨站不带 Cookie、HTTPS 下自动启用SecureCSRF 攻击的生存空间被进一步压缩。最快理解Nonce 制 CSP 如何封死脚本注入CSPContent-Security-Policy是浏览器执行的一道白名单机制。Hister 在给 Web 界面下发index.html时server/endpoints.go#L166-L178做了两件关键的事响应头注入Content-Security-Policy: script-src strict-dynamic nonce-随机值把页面里每个script标签替换为带相同nonce的形式。nonce是每次请求生成的随机字符串见 server/server.go#L175攻击者就算成功注入了脚本代码也无法猜中当前页面的随机值脚本会被浏览器直接拒绝执行。strict-dynamic模式还允许页面脚本按需加载其动态引入的子脚本兼顾了安全与 Svelte 前端框架的运行需求。日志脱敏敏感内容只过不留访问日志是信息泄露的重灾区。Hister 的日志中间件withLoggingserver/server.go#L396-L403对每条 Web 请求只记录四个字段Method Status LoadTimeMS URL也就是说日志里只有方法、状态码、耗时和请求路径——你在索引里存了哪些文档、搜索了什么关键词、文档正文内容统统不会出现在日志文件中。对于存放个人收藏、工作资料甚至敏感调研内容的私有知识库来说这条少记原则本身就是重要的隐私保护日志可以放心用于运维排障而不必担心其中沉淀了用户数据。想深入源码从这里入手CSRF 中间件server/server.go会话与 Token 存储server/session.goToken 以 SHA-256 哈希入库数据库泄露也不等于会话泄露CSP 下发逻辑server/endpoints.goHTTP API 开发约定含 CSRF 说明webui/website/src/content/docs/developer.md小结Hister 的安全设计思路很清晰CSRF 轮换 Token 防伪造、Nonce 制 CSP 防注入、最小化日志防泄露三者叠加构成了自托管搜索引擎的完整防护闭环。作为普通用户你几乎不需要做任何额外配置——启用 HTTPS 后这些防线即自动生效而作为开发者只需在 server/api.go 中声明 Endpoint路由、鉴权与 CSRF 处理都会保持一致。【免费下载链接】histerYour own search engine项目地址: https://gitcode.com/GitHub_Trending/hi/hister创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Hister安全设计解析CSRF、CSP与敏感内容日志脱敏【免费下载链接】histerYour own search engine项目地址: https://gitcode.com/GitHub_Trending/hi/histerHister 是一个自托管的私有搜索引擎Your own search engine它把网页存档、全文检索和语义搜索收进你自己的服务器。正因为数据高度私密Hister 在 Web 服务层做了三层经典安全防护CSRF 防跨站伪造请求、基于 Nonce 的 CSP 防脚本注入以及刻意少记的访问日志脱敏设计。本文带你用最短的时间看懂这三道防线。三道防线总览Hister 的服务端代码集中在 server/ 目录安全设计主要分布在三个文件里防线作用源码位置CSRF Token 校验阻止第三方网页伪造你的操作server/server.go#L340-L393Nonce 制 CSP阻止外部脚本注入与执行server/endpoints.go#L166-L178访问日志脱敏敏感内容不落盘到日志server/server.go#L396-L403一键看懂CSRF 是怎么被拦下的CSRF跨站请求伪造的典型场景是你已登录 Hister然后点开了一个恶意网站它偷偷以你的身份调用 Hister 的删除、写入接口。Hister 在withCSRF中间件server/server.go#L340-L393里是这样防的默认拒绝写操作只有GET和HEAD是安全请求其余方法必须携带 CSRF Token双重通道提交Token 可以从表单字段或X-CSRF-Token请求头提交服务端与 Session 中存储的 Token 逐一比对不匹配直接返回403 Forbidden每次响应都轮换 Token校验通过后服务端生成新 Token通过X-CSRF-Token响应头返回给前端旧 Token 立即失效攻击者截获的过期 Token毫无用处来源白名单来自本机命令行Origin: hister://、同源请求Sec-Fetch-Site: same-origin和浏览器扩展的请求走各自通道其中扩展来源如moz-extension://由浏览器控制网页无法伪造注释里写得很明白。配合 Cookie 层的加固——server/session.go#L39-L56 中 Session Cookie 设置了HttpOnlyJS 读不到、SameSiteLax跨站不带 Cookie、HTTPS 下自动启用SecureCSRF 攻击的生存空间被进一步压缩。最快理解Nonce 制 CSP 如何封死脚本注入CSPContent-Security-Policy是浏览器执行的一道白名单机制。Hister 在给 Web 界面下发index.html时server/endpoints.go#L166-L178做了两件关键的事响应头注入Content-Security-Policy: script-src strict-dynamic nonce-随机值把页面里每个script标签替换为带相同nonce的形式。nonce是每次请求生成的随机字符串见 server/server.go#L175攻击者就算成功注入了脚本代码也无法猜中当前页面的随机值脚本会被浏览器直接拒绝执行。strict-dynamic模式还允许页面脚本按需加载其动态引入的子脚本兼顾了安全与 Svelte 前端框架的运行需求。日志脱敏敏感内容只过不留访问日志是信息泄露的重灾区。Hister 的日志中间件withLoggingserver/server.go#L396-L403对每条 Web 请求只记录四个字段Method Status LoadTimeMS URL也就是说日志里只有方法、状态码、耗时和请求路径——你在索引里存了哪些文档、搜索了什么关键词、文档正文内容统统不会出现在日志文件中。对于存放个人收藏、工作资料甚至敏感调研内容的私有知识库来说这条少记原则本身就是重要的隐私保护日志可以放心用于运维排障而不必担心其中沉淀了用户数据。想深入源码从这里入手CSRF 中间件server/server.go会话与 Token 存储server/session.goToken 以 SHA-256 哈希入库数据库泄露也不等于会话泄露CSP 下发逻辑server/endpoints.goHTTP API 开发约定含 CSRF 说明webui/website/src/content/docs/developer.md小结Hister 的安全设计思路很清晰CSRF 轮换 Token 防伪造、Nonce 制 CSP 防注入、最小化日志防泄露三者叠加构成了自托管搜索引擎的完整防护闭环。作为普通用户你几乎不需要做任何额外配置——启用 HTTPS 后这些防线即自动生效而作为开发者只需在 server/api.go 中声明 Endpoint路由、鉴权与 CSRF 处理都会保持一致。【免费下载链接】histerYour own search engine项目地址: https://gitcode.com/GitHub_Trending/hi/hister创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
