部署SWA与Container App时，如何安全配置Express Session的BFF会话认证？

针对你的Azure部署架构（Front Door + Static Web Apps + Container Apps），Express Session设置secure: true失效的核心问题在于代理信任配置、请求头传递以及Cookie参数的细节调整，以下是具体修复步骤：

1. 修正代理信任配置 #

Azure Front Door属于多级反向代理架构，仅设置trust proxy: 1无法正确识别所有代理层级，导致Express无法判断请求的真实协议（HTTPS）。将代理信任设置改为：

if (config.environment !== "development") {
    app.set("trust proxy", true);
}

该配置会让Express信任所有反向代理传递的X-Forwarded-*头，适配Azure的动态代理环境。

2. 调整Session Cookie参数 #

结合你的同域名跨路径场景（development.mydomain.com/editor和/api），优化Cookie配置：

export const sessionMiddleware = session({
    secret: config.session.secret,
    resave: false,
    saveUninitialized: false, // 禁止创建空会话，减少无效请求并提升安全性
    proxy: true, // 必须启用，配合trust proxy解析真实请求协议
    cookie: {
        secure: true, // 生产环境强制启用Secure标记，仅通过HTTPS传输
        httpOnly: true, // 禁止前端JS访问Cookie，防范XSS
        maxAge: 24 * 60 * 60 * 1000,
        sameSite: "lax", // 同域名跨路径场景下，Lax既保证安全又兼容正常请求
        domain: ".mydomain.com", // 覆盖所有子域名，确保SWA和BFF共享会话Cookie
        path: "/", // 显式指定Cookie生效路径，避免子路径访问限制
    },
});

3. 验证Azure Front Door配置 #

确保Front Door满足以下要求：

• 强制所有请求使用HTTPS，在路由规则中配置重定向策略
• 保留并传递X-Forwarded-Proto请求头（Front Door默认会传递，但需确认未被自定义规则移除）
• 自定义域名已绑定有效SSL证书，确保HTTPS链路正常

4. 调试验证步骤 #

• 打开浏览器开发者工具的Application标签，检查Cookie列表：确认会话Cookie存在，且包含Secure、HttpOnly、SameSite=Lax标记
• 查看Container Apps的日志，确认请求头中的X-Forwarded-Proto值为https
• 测试跨路径请求：从/editor发起的/api请求需携带会话Cookie，后端能正确识别会话

内容的提问来源于stack exchange，提问作者LilumDaru