本文说明 Astralium 处理使用者资料的方式：资料流经哪些位置、每一段由谁保管、以及各项控制措施如何被验证。文中的设定与数字可对照本站公开的 HTTP 响应头，以及仓库中的资料库迁移档。
文末列出本文不涵盖的范围。
命盘计算在浏览器完成
紫微斗数、八字、西洋占星、印度占星、六爻、奇门遁甲六套排盘引擎随前端一同打包。星曜落宫、四化飞化、干支藏干、宫位与相位的计算在使用者的浏览器内完成，不经过我们的服务器。
本机排盘历史
排盘历史储存于浏览器的 localStorage，为定长环形缓冲，依帐号分桶。未登入状态下，历史仅存在于当前装置。
地理编码经由服务端
出生地名需转换为经纬度与时区，才能计算真太阳时。此步骤经由本站 API 端点 /api/resolve-birth-place 完成：服务端持有第三方地图服务金钥并快取结果，金钥不下发至浏览器，重复的地名不重复外查。
写入资料库的时机
未登入使用时，上述流程不产生资料库写入。仅在使用者主动建立出生档案，或执业者建立客户、个案与资料包版本时，资料才写入 Supabase。
目前生效的响应头
全站响应包含五项安全标头。CSP 的完整内容为：
- Content-Security-Policy —— 限制可执行的脚本来源，详见下节
- Strict-Transport-Security —— 强制 HTTPS 连线，不接受降级
- X-Frame-Options: DENY 与
frame-ancestors 'none'—— 禁止任何来源以 iframe 嵌入本站（点击劫持） - Referrer-Policy: strict-origin-when-cross-origin —— 跨站请求仅送出来源网域，不送完整网址
- Permissions-Policy —— 关闭相机、麦克风、地理位置、付款介面与 USB 存取
该组合于 securityheaders.com 的评等为 A+。
script-src 不含 unsafe-inline
本站的 script-src 不含 'unsafe-inline'，也不含 'unsafe-eval'。这是 CSP 能提供的最强防护形态。实际效果是以下各项全部不执行：
- 注入的内联脚本
onerror等事件处理属性javascript:连结eval与字串形式的setTimeout- 来自未列名来源的外部脚本
本站建置产物中内联可执行脚本数量为 0，涵盖 329 个预渲染 HTML 档全数检查；397 个 JavaScript 分块中亦无 eval、new Function 或 WebAssembly 编译呼叫。
相较之下，'unsafe-inline' 允许页面执行任何内联脚本；带有它的 script-src 对跨站脚本几乎不提供保护，因为注入的内联脚本依然会执行。它之所以在已部署的 CSP 中普遍存在，原因不在于设定复杂，而在于移除它不是设定项，是前端写法上的约束：送至浏览器的 HTML 中不能有任何内联可执行脚本。对已使用内联脚本的既有站点，移除成本通常等同于一次前端改写。
script-src 的完整内容，其中是否带有 'unsafe-inline' 一望即知。若某站根本没有 content-security-policy 这个标头，表示未设定 CSP。名单中的 connect.facebook.net
script-src 名单列有 connect.facebook.net，但本站并不加载这个脚本。Meta 的应用程式内建浏览器（Threads、Instagram、Facebook）会向其所渲染的每一个页面注入该脚本，用于广告转换归因；列名是为了让这类来源的流量下归因得以运作。
代价一并列出：名单中的来源可在本站的源上执行脚本，因此本站与该来源的安全状况相连。这是所有采用 Meta 转换追踪的站点承担的同一项取舍。此项与本站功能无关——移除后不影响任何操作，仅使该管道的广告归因失效。
策略中省略 default-src
本站策略未设定 default-src。未列出的指令因此不受限制——新增字型、图片来源或内嵌页面不会因 CSP 而失效。
此为覆盖面与维护面之间的取舍。省略 default-src 后，需要修改策略的情况收敛为单一种类：前端新增一个外部脚本来源。取舍的理由是策略的存活率：一条在日常开发中频繁造成故障的策略，会在某次除错中被放宽，之后不再恢复。
各段由谁保管
- 付款 · Stripe —— 结帐为整页跳转至 Stripe 托管页面。本站前端未安装
@stripe/stripe-js。卡号不经过本站页面，亦不经过本站服务器；服务端接收的是 Stripe 回传的订阅状态。 - 资料库与身份验证 · Supabase —— 帐号间的资料边界由列级安全策略划定，内容见下节。
- 传输与部署 · Vercel —— TLS 凭证、边缘网路与部署流程。
- 错误监控 · Sentry —— 设定为
sendDefaultPii: false，未启用 session replay 与效能追踪。收集错误型别、堆叠与浏览器环境，不含预设个人识别资讯，不录制操作画面。
跨帐号隔离由资料库执行
目前 18 张资料表启用列级安全，分为两种形态：
- 13 张带有以使用者为範圍的策略，合计 40 条，形式为限定
auth.uid()与资料列拥有者相符。 - 5 张不设任何策略——地理编码快取、意见回馈、推荐滥用记录与两张 Stripe 幂等表。列级安全的预设行为是全部拒绝，因此这些表以任何使用者凭证皆无法读取，仅服务端金钥可存取。
例如出生档案的读取策略：
隔离规则位于资料库层而非应用层。即使绕过应用程式直接以使用者凭证查询，资料库亦不回传他人资料列。
上述策略全部写在版本控制中的迁移档内，非于管理后台设定。每次变更均有提交记录与审查流程。
隔离的自动化验证
设定正确与行为正确需分别确认。仓库中的验证程式会建立两个临时帐号，以其中一个身份尝试读取另一个帐号的资料列，断言回传为空，随后删除两个帐号。
CSP 转强制前的观察期
会拦截请求的策略若设定有误，失效形式为页面功能静默中断。因此该策略先以 Content-Security-Policy-Report-Only 模式上线，仅记录不拦截，观察七日真实流量。
期间记录到的违规无一来自本站程式码，全部来自各应用程式内建浏览器注入的追踪脚本。确认后方转为强制模式。转换当日另于生产环境注入受控的测试脚本，确认拦截确实生效。
本文涵盖到哪里
本文涵盖的风险类别
- 跨站脚本执行
- 点击劫持
- 连线降级
- 跨帐号越权读取
- 付款资料经手
本文不涵盖的部分
- 供应商自身的安全实践与合规（Supabase / Vercel / Stripe 各有公开文件）
- 使用者的帐号密码强度
- 装置是否与他人共用
上列措施对应的是具体的风险类别，不等同于「安全」这一整体状态。
执业者若需向客户说明资料处理方式，可直接引用本页。本文未涵盖的问题，可由联络我们 提出。