普通视图

发现新文章，点击刷新页面。

昨天以前首页

苹果瞒着你给 iPhone 打了个补丁，为什么？

爱范儿

作者杜晨

2026年4月10日 10:10

今年 3 月的某一天，你的 iPhone 悄悄地自己更新了一次。

这次更新，既没弹出通知，也不会在系统更新菜单里体现，你甚至不需要点「同意」。要不是这篇文章，你或许压根不知道有过这么一次更新。

记忆里苹果过去没这么干过。考虑到「库克桌上的小按钮」这个都市传说，估计有人要怀疑，苹果莫非又在偷偷搞「计划报废」了？

放宽心，情况并没那么严重……这次推送的其实是个安全补丁，修复了可以让恶意网站绕过浏览器安全边界的 WebKit 漏洞。

但正如前面提到，这次更新没有走正常的系统更新流程，而是在联网的情况下，直接静默推送并安装了。当然，苹果也没有故意藏着掖着，官方网站上会有详细的日期和漏洞记录。

其实，这是是苹果的全新的安全推送机制「后台安全改进」Background Security Improvements，首次发挥作用。

过去十几年里，任何科技产品的安全更新，走的都是传统的流程：汇报/发现漏洞，开发补丁，打包进下一个系统版本，推送，等用户点同意下载、安装并重启。

这个逻辑，已经很多年没变过了，也没有任何改变的需要：If it ain’t broken, don’t fix it. 如果没有坏，为什么要改变？

但逻辑成立有一个前提：攻击方和防守方的速度大致对等。

现在的问题是，随着 AI 技术的进步，节奏开始变得越来越快：漏洞发现变快了，被滥用甚至大规模使用更快。留给科技公司给产品打补丁的窗口期越来越短。

科技公司们，也开始跟不上自己创立的新时代了。

2023 年，苹果曾经在 iOS 16 上做过一个「快速安全响应」的机制，能够静默完成安全升级。不过，该功能推出之后并没有没有有效利用，中间还有一次因为推送了错误的代码，导致一些网站无法正常显示，结果那次更新很快就撤回了，这个机制后来也没有再使用过。

但这次不一样了。今年，苹果从 iOS/iPadOS/macOS 26.1 版本开始启用「后台安全改进」政策，第一次实际投入使用，则是在 iOS 26.3 下的小版本上，也即开头提到的 WebKit 漏洞修补。

其原理大概如下：把 Safari、WebKit 等这些最容易被攻击的组件，给单独剥离出来，放进可以独立更新的加密磁盘镜像，从而绕开整个常规 OTA 流程。

「后台安全改进」的官方说明其实写的很简单，但通常字少事大。苹果的逻辑很明确：在今天这个时代，安全这件事不能等，必须加速。

时间再拨回本周：苹果加入了现如今最当红的 AI 巨头公司 Anthropic 发起的 Glasswing 计划，拿到了该公司最新，同时也是迄今为止最重磅的大模型 Mythos 的使用权。

这个模型能做很多事，但最擅长的能力之一，就是在那些每天数以亿万计用户使用的产品里，发现那些藏得最深但从未被此前任何方式发现的代码漏洞。

正式启用「后台安全改进」，和加入 Glasswing 计划，相隔不到一个月的这两件事放在一起，你应该能看出苹果有多看重安全了：

要知道，安全以及隐私是苹果最大的叙事主题，它必须尽最大努力去做好安全——哪怕是「瞒着用户」也要这么做。

从 Mythos 里面，苹果能得到什么？

Glasswing 计划的成员包括苹果、亚马逊、谷歌、微软、英伟达、思科、Palo Alto Networks、Linux 基金会等顶级公司和机构，另有 40 多个组织获得扩展访问权限，总计参与机构超过 50 家。

Mythos 是 Anthropic 目前最强的模型，所以你可以把 Glasswing 理解为 A 社拉了一个「内测群」……

这个模型没有公开发布，甚至连最顶级的付费用户（个人或企业）都暂时用不上。这在 AI 行业是非常罕见的，要知道放在任何其他公司，都会忍不住会把最新模型用最快速度推向市场，以获得更多的收入（为此甚至不惜给老模型降智、砍算力）。

A 社决定不第一时间全量开放 Mythos，提供的官方理由是：他们判断这个模型的能力可能越过了某条红线。

根据 Mythos 模型卡提供的信息，A 社并没有专门训练它去做安全用途，而是因为代码能力实在太强，进而导致 Mythos 涌现出了强大的攻防能力。

专门负责找破绽的 A 社红队，主动诱导 Mythos 从隔离的测试沙盒里「逃脱」，结果它还真发现了沙盒有一条设置错误的规则（并非人为设计，是真的疏忽），于是顺着这条路获取了特权，突破出站过滤，然后给研究员发了一封邮件，告知任务完成。

除了一开始的诱导提示词之外，没有人提供实质性的指导，模型自己完成了整个侦察、渗透、出逃的行为链。

A 社在报告里专门说明，这仅仅证明了 Mythos 大模型的能力超出预期，并不意味着它具备了某种自主意志（不论善良中立抑或邪恶）。

但与此同时，Mythos 会拒绝 96.7% 的明确恶意请求，以及 93% 不到的攻防双重用途请求——这仍然意味着，在 3-7% 不等的情况下，恶意请求可能会被执行。

而考虑到 Claude 月均 25 亿 API 调用，换算日均约 8.3 亿次调用——个位数百分点的比例，仍然可以换算为每天可能会有海量的恶意请求会被放过去、执行。哪怕只有一条成功了，都有可能造成糟糕的后果。

模型能力之强，已经真实地引发了它的创造者，以及整个科技世界的担忧。

于是，A 社提出了 Glasswing 这个「内测计划」：与其把 Mythos 锁进保险柜，不如让潜在暴露风险最高的巨头公司和机构们先拿到它，扫描自己产品里的漏洞，在更大范围扩散之前把洞堵上。

为此计划，A 社将会投入 1 亿美元的使用额度（本质上就是给内测伙伴提供 API 额度补贴），另外捐出 400 万美元给开源安全组织。

苹果拿到这个访问权限，扫描的对象是 iPhone 和 Mac，是 iOS、macOS、Safari——每天数以十亿计用户在使用的产品和操作系统。

苹果为什么看重 Mythos？它自己的安全团队不够格吗？当然绝非如此。

问题在于：

一个典型的安全研究员，对于系统安全有深刻的理解，但他可能不像 iOS/Unix/内核的工程师那样，对于专精的技术栈、某种具体的编程语言，有足够深的理解；
反之亦然，一个专精于 iOS/Unix/内核的工程师，能用自己的技术栈和熟练语言写出合格的代码，但仍然难免留下漏洞。
更别提今后的工程师遇到 bug，甚至都不用 Stack Overflow了，直接 Claude Code 就行，能力的全面性大不如前。

正如前面提到，Mythos 的攻防能力，来自于强大的代码能力。代码也强，攻防也强，相当于既是专业的 iOS 开发者，也是顶级的安全研究员。

两手一起抓，两手都很硬：这才是苹果真正看重的东西。

窗口正在关闭

Mythos 的战绩可查：在每一个主流操作系统，和每一个主流浏览器里，它都已经发现了此前未知的高危漏洞，总数达到数千个。其中超过 99% 在报告发布时仍未修复，正在走协调披露的流程。

这其中就有 OpenBSD。作为开源世界里公认安全标准最高的操作系统之一，OpenBSD 是很多防火墙和关键基础设施的底层系统，其代码库长期处于全球安全研究员的持续审计之下。

但是，Mythos 轻而易举地在其 TCP 协议里发现一个整数溢出漏洞，存在了长达 27 年之久但此前从未被发现，所花费的算力成本不足 50 美元。

OpenBSD 可能离你太远，FFmpeg 应该足够近了，它是几乎所有视频播放 App 的底层基础，每一个带有视频播放功能的应用，包括你正在看这篇文章用的微信或者浏览器，都内嵌了 FFmpeg 或其衍生技术。

Mythos 在 FFmpeg 的 H.264 解码器里找到了一个存在超过 16 年的 bug。自动化测试工具此前已对该代码路径运行了上百万次检查，也是从没发现问题的存在。

你的苹果设备浏览器多少都会利用 WebKit，你的路由器同样可能依赖某个 BSD 变种运行，短视频产品更是无处不在……这些软件、技术，存在于我们每天都在使用的手机、电脑等各种设备当中。

每台设备，每个人都会成为攻击对象，这绝对不是危言耸听了。安全这件事，现如今真的和每个人相关，而且关系从未如此紧密。

漏洞本身不是新鲜事。每年被登记在册的 CVE 漏洞编号数以万计。安全行业的人对这件事，早已形成了习以为常的应对节奏。

这套节奏建立在一个前提上：攻击者需要时间。发现一个漏洞，理解它的成因，写出可以稳定复现的利用代码，这个过程在以前需要数周到数月，高度依赖顶级安全研究员的经验积累。

防守方也慢，但大家都慢，所以系统能维持一种缓慢的均衡：根据 Verizon 的《数据泄露调查报告》，去年各种已知漏洞修复时间的中位值是一个月。

一个月，成了多年以来行业默认接受的风险敞口。然而，强有力的大模型今天已经将防守方的时间窗口压缩到以小时计：

以 Mythos 对 Linux 系统的漏洞利用为例，从自主完成侦察、漏洞分析、构建代码，完成 Linux 内核的提权——整个过程用时只用了半天左右，算力成本仅用了 2000 美元。

换成人类安全研究员，却要花至少一个人月（真实场景下可能需要多人）的薪资成本，才能完成这个修复。

但现在，我们没有时间了。

苹果的两步棋

现在你应该明白，苹果为什么要绕过你直接打补丁了。

正如前面提到，传统的 OTA 周期天然存在延迟。内外部人员发现漏洞，苹果开始开发修复代码，把它打包进一个完整的系统更新，走测试、审核、推送流程，最后等用户在某个方便的时刻点击安装——整个周期通常需要几周时间。

以前合理的东西，现在不合理了。苹果可能早在 2023 年就已经意识到了这一点。今年正式上线的「后台安全改进」，是苹果的最直接回应。

而成为 Glasswing 计划的核心合作伙伴，更是苹果在 AI 时代，提前布局安全的工作体现。「后台安全改进」让推送补丁的周期变短，用上大语言模型，解决的则是推送修复的前置工作——发现漏洞和生成补丁。

AI 的新时代，带来了新的威胁。整个安全响应链条，从发现到修复到推送，每一个环节都需要提速。

好在，大模型本身也可以被看作一种「平权」，只要能够支付得起 token 费用，无论巨头公司还是中小企业，甚至个人开发者，都能够借助其力量来让自己的产品变得更安全。

更何况模型的商品化趋势极为显著。或许在不久的将来，取得同样效果，只需要几十甚至上百分之一的成本（Mythos 费用是 $25/$125 每百万 token）。

然而，道高一尺，魔高一丈。只要有新的技术出现，就会出现新的攻击面。安全的猫鼠游戏从来没有真的结局，魔与道的交手永不停歇。

#欢迎关注爱范儿官方微信公众号：爱范儿（微信号：ifanr），更多精彩内容第一时间为您奉上。

为什么禁止我请求别的网站的接口？——跨域与CORS

掘金前端

作者牛奶

2026年4月7日 09:54

你有没有遇到过这种情况：在自己的网页上想请求别人的API，结果浏览器直接报错：Access-Control-Allow-Origin' header is missing。为什么浏览器要阻止你？服务器不响应不就完了吗？

今天，用小区门禁的故事，来讲讲 跨域 与 CORS。

原文地址

墨渊书肆/为什么禁止我请求别的网站的接口？——跨域与CORS

什么是"跨域"？

同源策略 — 浏览器的安全基石

浏览器有个同源策略（Same-Origin Policy）：只有来自同一个"家"的资源才能随便用。

什么叫"同一个家"？看三个条件：协议（http/https）、域名（example.com）、端口（:8080）。三个都一样，才是同源；有一个不一样，就是跨域。

跨域的例子

✅ http://example.com 和 http://example.com/profile     // 协议+域名+端口都相同 → 同源
✅ https://example.com 和 https://example.com           // 协议+域名+端口都相同 → 同源
❌ http://example.com 和 https://example.com           // 协议不同 → 跨域
❌ http://example.com 和 http://api.example.com        // 域名不同（子域名）→ 跨域
❌ http://example.com:8080 和 http://example.com:3000  // 端口不同 → 跨域

跨域限制了什么？

浏览器的同源策略主要限制了三件事：

DOM 访问：无法读取不同源的 iframe 内容、无法修改不同源的 iframe DOM
AJAX 请求：无法请求不同源的 API
Cookie/LocalStorage：无法访问不同源的数据

为什么要限制跨域？

模拟一个攻击场景

想象一下：你登录了银行网站 bank.com，浏览器保存了你的登录 Cookie。

然后你手滑点进了一个恶意网站 evil.com，这个网站里有一段代码：

<form action="http://bank.com/transfer" method="POST">
  <input type="hidden" name="to" value="hacker">
  <input type="hidden" name="amount" value="1000000">
</form>
<script>document.forms[0].submit();</script>

如果没有同源策略，这个表单请求会自动带上 bank.com 的 Cookie，银行服务器以为是你本人操作的——钱就没了。

同源策略就是浏览器的"门禁"：只有同一家人才能进，陌生人要查证件。

💡 注意：<img> 标签的 GET 请求虽然也会带 Cookie，但现代浏览器有 SameSite Cookie 保护。上面表单 POST 场景更典型。

CORS — 跨域的"通行证"

CORS 是什么？

CORS（Cross-Origin Resource Sharing）= 跨域资源共享。

它的工作原理很简单：让服务器告诉浏览器，"我允许来自这些源的请求"。

简单请求 vs 预检请求

简单请求

满足以下条件的请求是"简单请求"：

条件	要求
请求方法	`GET`、`POST` 或 `HEAD`
请求头部	只有几种常见类型
Content-Type	只能是 `application/x-www-form-urlencoded`、`multipart/form-data` 或 `text/plain`

简单请求的流程：

1. 浏览器发送请求（自动带上 Origin 头）
   ↓
2. 服务器检查 Origin，决定是否允许
   ↓
3. 服务器返回响应头 Access-Control-Allow-Origin
   ↓
4. 浏览器检查响应头，允许就完事

服务器端示例（Node.js）：

app.get('/api/data', (req, res) => {
  const origin = req.headers.origin;

  if (origin === 'https://example.com') {
    res.setHeader('Access-Control-Allow-Origin', origin);
  }

  res.json({ data: '这是返回的数据' });
});

响应头：

HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://example.com
Content-Type: application/json

{"data": "这是返回的数据"}

预检请求（Preflight）

不满足"简单请求"条件的，浏览器会先发一个 OPTIONS 请求"探路"：

1. 浏览器发送 OPTIONS 预检请求
   ↓
2. 服务器检查方法/头部/Origin
   ↓
3. 服务器返回允许的头 Access-Control-*
   ↓
4. 浏览器发送实际请求

预检请求检查什么？

预检请求（OPTIONS）就像登机前的安检——先检查你带没带危险品。

浏览器会问服务器三件事：

我从哪来？（Origin）
我想用什么方法？（Access-Control-Request-Method）
我想带什么头？（Access-Control-Request-Headers）

服务器回答"可以"，浏览器才放行实际请求。

# 请求（浏览器发给服务器）
OPTIONS /api/data HTTP/1.1
Origin: https://example.com              # 我从哪来
Access-Control-Request-Method: PUT        # 我想用 PUT 方法
Access-Control-Request-Headers: Content-Type, Authorization  # 我想带这些头

---

# 响应（服务器告诉浏览器）
HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://example.com  # 允许这个源
Access-Control-Allow-Methods: GET, POST, PUT, DELETE  # 允许这些方法
Access-Control-Allow-Headers: Content-Type, Authorization  # 允许这些头
Access-Control-Max-Age: 86400          # 预检结果缓存24小时

服务器端处理：

app.options('/api/data', (req, res) => {
  const origin = req.headers.origin;

  if (origin === 'https://example.com') {
    res.setHeader('Access-Control-Allow-Origin', origin);
    res.setHeader('Access-Control-Allow-Methods', 'GET, POST, PUT, DELETE');
    res.setHeader('Access-Control-Allow-Headers', 'Content-Type, Authorization');
    res.setHeader('Access-Control-Max-Age', '86400');
  }

  res.status(204).send();
});

CORS 响应头详解

常用响应头

响应头	作用	例子
`Access-Control-Allow-Origin`	允许的源	`*` 或 `https://example.com`
`Access-Control-Allow-Methods`	允许的方法	`GET, POST, PUT`
`Access-Control-Allow-Headers`	允许的头部	`Content-Type, Authorization`
`Access-Control-Max-Age`	预检缓存时间	`86400`（秒）
`Access-Control-Allow-Credentials`	是否允许带 Cookie	`true`

credentials 模式

默认情况下，CORS 不带 Cookie。如果需要携带 Cookie：

前端：

fetch('/api/data', {
  credentials: 'include'
});

服务端：

res.setHeader('Access-Control-Allow-Origin', 'https://example.com');
res.setHeader('Access-Control-Allow-Credentials', 'true');

注意：Access-Control-Allow-Origin 不能用 *，必须是具体域名。

跨域的解决方案

1. JSONP（已不推荐）

利用 <script> 标签不受同源策略限制的特性：

<script>
  function handleData(data) {
    console.log(data);
  }
</script>
<script src="http://api.example.com/data?callback=handleData"></script>

缺点	说明
只支持 GET	无法处理 POST 等请求
有安全风险	可能被注入恶意代码
无法捕获错误	错误处理困难

2. 代理服务器

在自己的服务器上转发请求，"伪装"成同源：

浏览器 ──> 我的服务器（同一源） ──> 目标服务器

Nginx 代理：

location /api/ {
  proxy_pass http://target-server.com/;
}

Node.js 代理：

app.get('/api/data', async (req, res) => {
  const response = await fetch('http://target-server.com/data');
  const data = await response.json();
  res.json(data);
});

3. Webpack/Vite 开发代理

开发环境配置代理：

// vite.config.js
export default {
  server: {
    proxy: {
      '/api': {
        target: 'http://target-server.com',
        changeOrigin: true
      }
    }
  }
};

4. postMessage

不同窗口/iframe 之间的通信：

window.addEventListener('message', (event) => {
  if (event.origin === 'https://example.com') {
    console.log('收到消息:', event.data);
  }
});

iframe.contentWindow.postMessage('hello', 'https://example.com');

深入了解 CORS 🔬

第三方 Cookie 的限制

现代浏览器正在逐步限制第三方 Cookie：

浏览器	政策
Chrome	计划逐步淘汰第三方 Cookie
Safari	默认阻止第三方 Cookie
Firefox	提供第三方 Cookie 阻止选项

CORS 和 CSRF 的区别

	CORS	CSRF
是什么	跨域资源共享机制	跨站请求伪造攻击
作用	服务端允许/禁止跨域请求	利用用户已登录状态发起攻击
防御	服务端配置 `Access-Control-*`	Token、SameSite Cookie、验证码

为什么 OPTIONS 叫"预检"？

"预检"就像登机前的安检——先检查你带没带危险品（方法、头部），没问题了才让你登机（发送实际请求）。

常见错误排查

错误 1：No 'Access-Control-Allow-Origin' header

原因	解决
服务端没配置 CORS	添加 `Access-Control-Allow-Origin` 头
Origin 不匹配	检查配置的域名是否正确
credentials 时用了 `*`	必须指定具体域名

错误 2：Method not allowed

原因	解决
请求方法（如 `PUT`）不在允许列表	检查 `Access-Control-Allow-Methods`

错误 3：Header not allowed

原因	解决
请求头部（如 `Authorization`）不在允许列表	检查 `Access-Control-Allow-Headers`

错误 4：预检请求 404

原因	解决
服务端没有处理 OPTIONS 请求	中间件或网关要放行 OPTIONS

总结

概念	像什么	作用
同源策略	小区门禁	限制不同源的访问，保护安全
CORS	通行证	告诉浏览器哪些跨域请求是允许的
简单请求	普通访客	不需要预检，直接请求
预检请求	安检验票	先检查再放行，更安全的请求
JSONP	走后门	已不推荐，有安全风险
代理	同一个家门	绕过跨域，最推荐的开发方案

写在最后

现在你应该明白了：

跨域是浏览器的安全机制，不是为了刁难你
CORS 是服务器授权机制，服务器说可以，浏览器才放行
预检请求 = 安检，OPTIONS 通过了才能发送实际请求
生产环境推荐用代理，开发环境用 webpack/vite 代理

下次遇到跨域错误，先看浏览器控制台的报错信息——是"缺通行证"（header 缺失）还是"通行证不对"（origin 不匹配），处理方式不一样的。