全站 HTTPS 部署实战指南Front-End-Checklist 的传输安全规则解析【免费下载链接】Front-End-Checklist The essential checklist for modern web development, for humans and AI agents项目地址: https://gitcode.com/gh_mirrors/fr/Front-End-Checklist本指南以 Front-End-Checklist 仓库中的security/transport核心规则「Serve all pages over HTTPS」为骨架系统讲解 HTTPS 的三大安全属性、Lets Encrypt/Certbot 免费证书签发、Nginx/Apache/Cloudflare 的 HTTP→HTTPS 301 重定向、安全上下文Secure ContextAPI 依赖清单、混合内容Mixed Content排查以及证书过期等常见陷阱的修复方案。读完本文你将掌握一套可在生产环境直接落地的全站 HTTPS 部署与验证流程。规则定位为什么全站 HTTPS 是安全基线而非可选项在 Front-End-Checklist 的规则体系中本规则属于security/transport分类优先级标记为critical关键难度为beginner入门预估耗时30 分钟。其核心断言是网站上的每个页面与每个资源都必须通过 HTTPS 交付以保护传输中的数据并启用现代浏览器特性。该规则的完整定义位于 skills/https/references/rule.md对应的结构化元数据优先级、难度、适用场景、检查/修复/解释提示词可在 skills/https/SKILL.md 中查看而站点内容层的等价表述则维护在 packages/content/rules/en/security/https.mdx。从仓库的规则组织方式可以看出HTTPS 不是孤立条目它与一组姊妹规则构成完整的传输安全矩阵skills/http-to-https/references/rule.mdHTTP→HTTPS 的 301 永久重定向skills/hsts/references/rule.mdStrict-Transport-Security响应头security/transport分类下的混合内容mixed-content规则、表单提交安全form-https规则以及Referrer-Policy规则。在 packages/content/rules/en/security/https.mdx 的relatedRules字段中这些规则被显式标记为「commonly reviewed together」常被一起审查说明一次完整的传输安全审计应当把上述条目作为一个整体来执行。HTTPS 到底是什么HTTP over TLS 的三重保证HTTPSHTTP over TLS在浏览器与服务器之间加密所有流量提供三个核心安全属性机密性Confidentiality网络路径上的第三方无法读取数据。明文 HTTP 会暴露每一次请求与响应——ISP、Wi-Fi 运营商和中间人MITM攻击者无需任何提示即可读到密码、会话令牌与个人数据完整性Integrity传输中的数据不可被篡改防止 ISP 或 MITM 攻击者注入内容例如在响应中注入广告或恶意脚本认证性Authentication证书证明服务器确实是它所声称的身份防止域名仿冒与钓鱼。规则文档引用了 MDN 的传输安全指南、web.dev 的「Why HTTPS Matters」以及 OWASP 的 Transport Layer Protection Cheat Sheet三者均将全站 HTTPS 视为安全基线baseline而非可选的加固步骤。这一点也写入了 packages/content/rules/en/security/https.mdx 的whyItMatters字段成为 Agent 审计时的标准判断依据。证书获取Lets Encrypt 免费证书与托管 TLSLets Encrypt Certbot自管服务器规则文档给出了最常用的免费证书签发路径——Certbot# 安装 Certbot含 Nginx 插件 sudo apt install certbot python3-certbot-nginx # Debian/Ubuntu sudo yum install certbot python3-certbot-nginx # RHEL/CentOS # 获取证书并自动配置 Nginx sudo certbot --nginx -d example.com -d www.example.com # Certbot 会自动设置续期 # 测试续期是否可用 sudo certbot renew --dry-run要点说明--nginx插件会自动改写 Nginx 配置、装载证书并配置 443 监听如需纯手动模式可改用certbot certonly --webroot关键同一命令中同时传入-d example.com -d www.example.com这样签发的证书会包含两个域名SAN 证书避免www子域出现证书错误——这正是「常见陷阱」一节专门列出的问题续期Certbot 安装后通常会自动创建 systemd timer 或 cron 任务执行续期务必用certbot renew --dry-run提前验证续期链路可用否则证书过期会直接导致浏览器拦截整个页面。托管平台 / 托管 TLS对于大多数托管平台TLS 是自动处理的规则文档的对照如下平台处理方式Vercel自动——所有部署自动签发证书Netlify自动——一键启用基于 Lets Encrypt 的 HTTPSAWS CloudFront使用 AWS Certificate Manager对 CloudFront 免费Cloudflare所有套餐均包含托管 TLS值得注意的是Front-End-Checklist 自身的 Web 应用就部署在 Vercel 上apps/web/vercel.json 中可以看到该平台项目的部署配置cron 任务、MCP 主机重写与 CORS 头这类平台在证书层面无需人工干预。此外apps/web/next.config.js 中images.remotePatterns只允许protocol: https的外部图片源如avatars.githubusercontent.com从源码层面印证了「所有资源都必须是 HTTPS」这一全站约束。HTTP→HTTPS 重定向服务器与边缘层配置证书就位后第二步是把所有明文 HTTP 流量永久重定向到 HTTPS。必须使用 301永久重定向——302 不会被浏览器缓存导致每次访问都先走一遍 HTTP既慢又危险。Nginx# 将所有 HTTP 重定向到 HTTPS server { listen 80; server_name example.com www.example.com; return 301 https://$host$request_uri; } server { listen 443 ssl http2; server_name example.com www.example.com; ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem; # ... }return 301 https://$host$request_uri;会保留原始主机名、路径与查询参数是最稳妥的写法。443 配置块同时开启http2因为 HTTP/2 本身要求 HTTPS 作为前提见下文安全上下文章节。ApacheVirtualHost *:80 ServerName example.com Redirect permanent / https://example.com/ /VirtualHost在 packages/content/rules/en/security/https.mdx 中Apache 示例使用了完整的VirtualHost包裹此处直接采用完整版。姊妹规则 skills/http-to-https/references/rule.md 还补充了 Apache 的mod_rewrite等价写法RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R301]以及 Caddy 的自动重定向redir https://{host}{uri} permanent。Cloudflare边缘层在 Cloudflare 控制台 →SSL/TLS → Edge Certificates中开启Always Use HTTPS并将Minimum TLS Version设为 1.2。该开关在 CDN 边缘生效请求到达源站之前即完成协议升级。重定向链问题多跳重定向会显著增加延迟规则文档给出正反示例❌ 错误http://example.com → http://www.example.com → https://www.example.com ✅ 正确http://example.com → https://example.com每一跳都增加一次往返。正确做法是把www/非www偏好与 HTTP→HTTPS 升级合并为单次 301。此外绝不能用 JavaScript如window.location.href https://...做安全重定向——JS 在 HTTP 响应送达之后才执行此时不安全的请求已经发出会话数据已然暴露。重定向之后叠加 HSTSHTTP→HTTPS 重定向稳定运行后应追加Strict-Transport-Security响应头让浏览器在发起任何网络请求之前就内部升级到 HTTPS彻底消除「第一次 HTTP 请求被劫持」的窗口Strict-Transport-Security: max-age31536000; includeSubDomainsHSTS 的完整配置Nginx/Apache/Next.js/Express Helmet、preload 预加载清单的六项准入要求详见 skills/hsts/references/rule.md它属于本规则之后紧接着要做的高优先级加固项。需要 HTTPS 的现代特性用「安全上下文」检查页面规则文档强调MDN 与 web.dev 都将下列 API 归类为安全上下文Secure Context特性——只有 HTTPS 页面或 localhost才能使用。它们因此成为发现「仍依赖不安全源」页面的实用探针如果一个页面声称启用了这些功能却在 HTTP 下运行浏览器会直接拒绝或降级。特性为何要求 HTTPSService Workers防止拦截缓存资源的网络请求Push Notifications推送通知需要身份认证Geolocation API地理定位隐私保护getUserMedia摄像头/麦克风隐私保护Web Crypto API安全要求Payment Request API支付请求金融数据保护HSTS、HTTP/2、HTTP/3协议本身的前提条件混合内容HTTPS 页面上的 HTTP 资源如果 HTTPS 页面加载了任何 HTTP 资源页面即被视为混合内容mixed content。其中主动混合内容active mixed content——脚本、iframe、样式表——会被浏览器直接拦截可能导致功能完全失效被动混合内容图片、音频等则会在地址栏显示不安全提示。因此必须全量审计资源 URLimg src、script src、link href、fetch()、axios请求等确保均为 HTTPS。常见陷阱对照表规则文档提供了一张高密度的问题诊断表是排障时的直接参考错误影响修复证书过期浏览器以安全警告拦截整个页面配置自动续期如通过 cron 执行certbot renew证书缺少wwwwww.example.com显示安全错误使用同时覆盖example.com与www.example.com的 SAN 证书HTTP 重定向使用 302浏览器不缓存重定向拖慢后续请求改用 301永久重定向仅在登录页启用 HTTPS其余页面数据在传输中暴露全站启用 HTTPS补充两个审计视角的注意点来自 skills/https/SKILL.md 的 Code Review 提示审查服务器配置、响应头、表单与集成点时应针对具体响应、Cookie 或浏览器行为来判定是否违反规则并对照生产环境的真实响应验证——不要只依赖框架层配置「看起来没问题」的静态判断。例外与边界Exceptions本地开发或纯内部环境可以有所不同但面向生产用户的流量必须严格满足传输要求在某个主机名、子域或 CDN 边缘路径上失效的重定向或 HTTPS 控制对到达该表面的用户和爬虫而言依然是真实故障修复时先解决最严重的传输弱点而不是把每个下游症状当作独立的独立问题分别处理。验证自动化与人工检查规则的验证策略分为两层见 skills/https/references/rule.md 的 Verification 章节自动化检查对一条有代表性的真实链路运行安全检测、脚本化探测或基于日志的校验。实践中可组合以下手段curl -sI https://example.com检查响应状态与Strict-Transport-Security等头全站抓取所有 URL断言http://均返回 301 且Location指向https://版本证书校验工具如 SSL Labs 的 ssltest目标评级 A 或 A验证证书链完整、未过期且覆盖所有主机名。人工检查在类生产流程中手动验证浏览器端行为并确认不存在更强的冲突性安全信号。特别地规则文档强调Support NotesHTTPS 行为必须在带真实证书链、重定向、代理与 CDN 路径的类生产环境中验证现代安全上下文特性在本地可能「看似正常」到了真实生产主机上却失败或降级——这也是把「证书 重定向 头」作为一个整体部署而非分步凑合的原因。在 Front-End-Checklist 仓库中的延伸阅读规则文档主体skills/https/references/rule.mdAgent 可执行提示词Check / Fix / Explain / Code Reviewskills/https/SKILL.md站点内容层规则含relatedRules关联关系packages/content/rules/en/security/https.mdx配套规则HTTP→HTTPS 重定向与重定向链skills/http-to-https/references/rule.mdHSTS 响应头与 preload 准入skills/hsts/references/rule.md生产示例Front-End-Checklist 自身的部署与安全头配置见 apps/web/next.config.jsCSP、Referrer-Policy、Permissions-Policy、X-Content-Type-Options、X-Frame-Options等与 apps/web/vercel.json【免费下载链接】Front-End-Checklist The essential checklist for modern web development, for humans and AI agents项目地址: https://gitcode.com/gh_mirrors/fr/Front-End-Checklist创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考