同一域名不同端口间如何安全跨端口传递参数？

Question

同一域名不同端口（如 `http://localhost:3000` 与 `http://localhost:8080`）在浏览器中仍被视为**不同源（origin）**，受同源策略严格限制，无法直接通过 `localStorage`、`sessionStorage` 或 `document.domain` 共享数据。常见误区是误以为“同域名即同源”，忽略端口差异导致跨端口通信失败。典型问题包括：前端尝试用 `fetch` 调用另一端口接口时触发 CORS 预检失败；使用 `postMessage` 但未校验 `event.origin` 和 `event.source`，存在 XSS 或中间人劫持风险；或依赖 URL 参数跳转传参，导致敏感信息泄露至服务端日志、浏览器历史及 Referer 头。此外，WebSocket 虽可跨端口建立连接，但需服务端显式支持且缺乏内置认证机制。如何在不降低安全性前提下，实现可信端口间参数的机密性、完整性与来源可控传递，是开发单页应用微前端、本地调试代理或多进程前端架构时的关键挑战。

Answer 1

```html

一、认知层：理解同源策略的本质与端口的决定性作用

同源（Same-Origin）由协议（scheme）、主机（host）和端口（port）三元组严格定义。即使 http://localhost:3000 与 http://localhost:8080 共享域名，端口差异即构成跨源——这是浏览器安全模型的基石，而非实现缺陷。开发者常误将“同域名”等同于“同源”，导致 localStorage 读写静默失败、fetch 被拦截、iframe 无法访问 contentWindow 等现象。

二、诊断层：典型故障模式与安全漏洞归因分析

• CORS 预检失败：当 fetch 发起非简单请求（如含自定义 header、Content-Type: application/json），浏览器强制发送 OPTIONS 预检，若服务端未正确响应 Access-Control-Allow-Origin、Access-Control-Allow-Methods 等头，则被阻断；
• postMessage 安全失守：未校验 event.origin === 'http://localhost:3000' 或未验证 event.source 身份，攻击者可伪造 iframe 注入恶意消息；
• URL 参数泄露链：通过 location.href = 'http://localhost:8080?token=xxx' 传递敏感参数，导致 token 泄露至服务器 access_log、浏览器 history API、Referer 头及代理日志中。

三、架构层：跨端口可信通信的四维设计原则

维度	要求	反例	合规方案
机密性	传输/存储中敏感参数不可被中间方或同域其他端口窃取	localStorage.setItem('auth', token)	内存驻留 + AES-GCM 加密 + 密钥派生于端口指纹
完整性	接收方能验证消息未被篡改且来源可信	postMessage({data: 'payload'})	JWT with HS256 + issuer/port-bound jti + signature verification

四、实践层：生产级跨端口通信方案选型与实现

以下为经高并发微前端项目验证的组合方案：

1. 本地开发代理统一入口：使用 Vite/Nginx 反向代理将 /api 映射至 http://localhost:8080，使前端始终调用 http://localhost:3000/api/xxx，规避 CORS；
2. 基于端口指纹的 postMessage 协议栈：

   const PORT_TRUST_LIST = new Set(['http://localhost:3000', 'http://localhost:8080']);
   window.addEventListener('message', (e) => {
     if (!PORT_TRUST_LIST.has(e.origin)) return;
     const payload = JSON.parse(e.data);
     if (!verifyJWT(payload.jwt, e.origin)) return; // 使用 origin 作为 JWT issuer 校验
     handleTrustedMessage(payload);
   });

3. WebSocket 增强认证通道：连接建立后，客户端立即发送携带 port 和 nonce 的签名凭证，服务端校验签名+端口白名单后升级为可信会话。

五、演进层：面向微前端与多进程架构的长期治理策略

graph LR
A[主应用 localhost:3000] -->|postMessage + JWT| B[子应用 localhost:8080]
A -->|SharedWorker + MessageChannel| C[共享状态中心]
B -->|WebSocket + TLS + mTLS 双向认证| D[网关服务]
C -->|IndexedDB 加密分片| E[持久化可信缓存]

六、验证层：自动化安全检测清单

• ✅ 所有 postMessage 接收端强制校验 e.origin 且白名单硬编码（禁止正则通配）；
• ✅ 敏感参数永不出现于 URL、document.cookie、localStorage、sessionStorage；
• ✅ WebSocket 握手阶段完成端口绑定 + 时间戳 nonce + HMAC-SHA256 签名验证；
• ✅ 使用 CSP connect-src 'self' http://localhost:8080 显式约束可连接端点；
• ✅ 构建时注入 PORT_IDENTITY_HASH 环境变量，用于运行时生成唯一加密盐值。

七、延伸思考：超越 localhost 的工程一致性

当从本地开发迁移到预发布环境（如 https://dev.example.com:3000 与 https://dev.example.com:8080），需同步升级方案：启用 HTTPS 强制、部署 CORB/CSP 严格策略、引入 OAuth 2.1 PKCE 流程替代端口间 token 透传，并通过 Service Worker 拦截并重写跨端口 fetch 请求为同源代理调用。此迁移路径本质是将“端口信任”升维为“证书链信任+策略即代码（Policy-as-Code）”。

```