CORS检查器

检查任意URL的跨源资源共享（CORS）配置。查看Access-Control-*响应头部，使用自定义Origin/方法/头部运行可选的预检（OPTIONS）请求，并检测常见配置错误，如通配符+凭据、缺少Vary: Origin，或允许头部范围过宽。

Loading…

关于 CORS检查器

粘贴API或页面URL，验证浏览器是否允许跨源请求。本工具分析CORS响应头部，可运行真实的预检（OPTIONS）检查，并高亮显示有风险或错误的配置（如“*”与凭据共用、缺少Vary: Origin，或允许方法/头部过弱）。

功能特色

  • 检查任意公开URL的CORS头部（Access-Control-*及相关头部）。
  • 可选的预检模拟（OPTIONS），支持自定义Origin、请求方法和请求头部。
  • 跟随重定向（最多10次），确保验证浏览器实际访问的最终端点。
  • 原始头部视图，提供完整的透明度和调试信息。
  • 发现结果 + 评分卡，支持“仅显示问题”筛选，便于快速排查。
  • Vary分析，检测缺失的Vary: Origin及其他与缓存相关的CORS陷阱。
  • 将结果导出为JSON和PDF报告，用于审计、工单和文档记录。
  • 内置常见问题建议：通配符+凭据、Origin反射、null Origin、缺失允许方法/头部、缺失max-age，以及允许头部范围过宽。

🧭 使用指南 for cors-checker

1

输入目标URL

粘贴您要测试的端点（例如：https://api.example.com/resource）。

2

设置您测试的Origin

输入您前端应用的Origin（协议 + 主机），例如：https://app.example.com。这是浏览器在Origin头部中发送的值。

3

选择检查模式

使用自动模式（推荐）同时分析响应头部和预检行为。若需特定非预检场景，请使用简单请求模式；若仅运行OPTIONS检查，请使用仅预检模式。

4

配置预检详情（如适用）

启用“运行预检（OPTIONS）”，并设置请求方法及请求头部（逗号分隔），以模拟真实浏览器的预检行为（例如：authorization、content-type）。若您的用例包含cookie或认证头部，请切换“考虑凭据”。

5

查看发现结果并导出

检查发现结果/评分卡及CORS分析详情。调试时可开启“显示原始头部”。导出JSON/PDF用于分享或审计存档。

技术规格

请求模型

本工具检查目标URL的CORS头部，并可选择使用提供的Origin、方法和请求头部执行预检（OPTIONS）请求。支持跟随重定向。

设置行为默认值
检查模式自动、简单请求或仅预检自动
运行预检（OPTIONS）若启用，将执行OPTIONS预检模拟已启用
来源用于分析/预检的Origin标头值https://example.com
请求方法预检使用的Access-Control-Request-Method值GET
请求标头预检使用的Access-Control-Request-Headers（逗号分隔）空
跟随重定向跟随重定向链至最终URL已启用
最大重定向次数防止循环的重定向上限10（范围0–20）
超时请求超时限制15000毫秒
用户代理标识请求的用户代理Encode64Bot/1.0 (+https://encode64.com)
私有网络出于安全考虑，阻止访问私有网络范围已禁用（不允许私有网络）

已分析标头（核心CORS集）

分析器专注于浏览器和预检检查使用的标准CORS响应与请求标头。

标头用途
Access-Control-Allow-Origin允许哪些来源
Access-Control-Allow-Credentials是否允许Cookie/凭据（需要非通配符来源）
Access-Control-Allow-Methods跨源请求允许的方法（对预检请求至关重要）
Access-Control-Allow-Headers允许的请求头（对Authorization和自定义头至关重要）
Access-Control-Expose-Headers浏览器JavaScript可读取哪些响应头
Access-Control-Max-Age浏览器可缓存预检请求结果的时间
Vary缓存键的变体（例如 Vary: Origin），用于防止缓存污染/混用
Origin / Access-Control-Request-*用于模拟预检请求行为

启发式规则（标记常见的CORS陷阱）

检查结果基于实用且注重安全的验证，旨在检测有缺陷或存在风险的CORS配置。

检查项重要性
通配符 + 凭据Access-Control-Allow-Origin: * 不能与凭据一起使用；浏览器会阻止或行为不安全
缺少 Vary: Origin如果响应因Origin而异但未正确缓存，共享缓存可能会在不同站点间混用响应
反射Origin盲目回显Origin可能会无意中允许不受信任的来源
Null Origin警告Origin: null 可能出现在沙盒iframe或文件上下文中；允许它通常存在风险
缺少 Allow-Methods / Allow-Headers如果服务器未明确允许方法/请求头，预检请求可能会失败
Allow-Headers 范围过宽允许过多的请求头可能会扩大攻击面
缺少 Max-Age预检请求可能过于频繁地执行，增加延迟
CORS是浏览器强制执行机制。非浏览器客户端仍可跨源访问服务器；应将CORS视为更广泛安全策略的一部分，而非唯一控制措施。

命令行

使用以下命令在终端中复现CORS和预检请求行为。它们有助于调试和验证工具报告的内容。

macOS / Linux

检查正常请求的CORS头（模拟浏览器Origin）

curl -i -H "Origin: https://example.com" https://api.example.com/resource

查找 Access-Control-Allow-Origin、Access-Control-Allow-Credentials 和 Vary。

执行预检OPTIONS请求（方法 + 请求头）

curl -i -X OPTIONS -H "Origin: https://app.example.com" -H "Access-Control-Request-Method: POST" -H "Access-Control-Request-Headers: authorization, content-type" https://api.example.com/private

预检请求必须返回正确的 Access-Control-Allow-Methods 和 Access-Control-Allow-Headers，浏览器才能继续执行。

检查响应头时跟随重定向

curl -iL -H "Origin: https://example.com" https://api.example.com

当端点重定向到具有不同CORS规则的其他主机时很有用。

Windows (PowerShell)

使用Origin头检查响应头

$r = Invoke-WebRequest -Uri https://api.example.com/resource -Headers @{ Origin = "https://example.com" }; $r.Headers

如果存在Access-Control-*头，则显示它们。

如果您的应用前端使用Cookie或身份验证，请避免使用过于宽松的CORS设置。建议明确指定受信任来源的白名单，并在响应因来源不同而不同时包含Vary: Origin头。

使用场景

调试前端“CORS被阻止”浏览器错误

当fetch/XHR因CORS错误失败时，验证服务器是否为您的来源和请求类型返回了必需的Access-Control-*头。

  • 确认Access-Control-Allow-Origin与您的应用来源匹配
  • 如果使用Cookie/身份验证，请检查Access-Control-Allow-Credentials是否为true（并且来源不是通配符）
  • 当允许多个来源时，确保存在Vary: Origin头

验证Authorization/自定义头的预检请求

大多数经过身份验证的API调用会因Authorization或非简单内容类型而触发预检请求。此工具有助于确保OPTIONS响应允许所需的方法和头。

  • 验证Access-Control-Allow-Methods根据需要包含POST/PUT/PATCH/DELETE
  • 验证Access-Control-Allow-Headers包含authorization、content-type以及必需的X-*头
  • 在部署前捕获缺失的allow-methods/allow-headers

CORS策略安全审查

CORS配置错误可能无意中将私有API暴露给恶意网站（尤其是在使用凭据时）。利用检查结果来发现高风险模式。

  • 检测通配符来源与凭据结合使用的情况
  • 检测允许任意站点的来源反射模式
  • 标记非预期情况下允许Origin: null的情况

通过缓存预检请求提升性能

预检请求会增加往返次数和延迟。正确的Max-Age设置可以减少对稳定API的重复预检检查。

  • 在适当时验证Access-Control-Max-Age是否存在
  • 减少频繁API流量中的重复OPTIONS调用

❓ Frequently Asked Questions

❓简单来说，什么是CORS？

CORS（跨源资源共享）是一种浏览器安全机制，用于控制来自一个来源（协议+主机+端口）的网页是否可以读取另一个来源的响应。它依赖于特定的Access-Control-*响应头。

❓浏览器何时会发送预检（OPTIONS）请求？

当请求不是“简单”请求时会发送预检请求，例如使用某些内容类型的POST方法，或发送Authorization或自定义X-*头时。浏览器会先通过OPTIONS请求检查权限，然后再发送实际请求。

❓为什么“Access-Control-Allow-Origin: *”在使用凭据时很危险？

浏览器在涉及凭据时要求明确的来源。将通配符与凭据结合使用对于带凭据的请求是无效的，并且表明存在风险配置。建议使用明确的受信任来源白名单。

❓为什么需要Vary: Origin？

如果您的服务器根据请求的Origin返回不同的Access-Control-Allow-Origin值，缓存必须根据Origin进行区分，以避免将为一个站点准备的响应提供给另一个站点。Vary: Origin有助于防止缓存混淆及相关安全问题。

❓CORS 能保护我的 API 免受非浏览器客户端的访问吗？

不能。CORS 是由浏览器强制执行的。在浏览器外运行的脚本（服务器、curl、移动应用）可以无视 CORS 调用您的 API。请使用身份验证、授权和速率限制来实现真正的访问控制。

❓测试预检请求时，我应该在“请求头”中填写什么？

列出您前端将要发送的请求头，用逗号分隔（例如：authorization, content-type, x-request-id）。这模拟了 Access-Control-Request-Headers 并检查服务器是否允许这些请求头。

❓在这里粘贴 URL 安全吗？

本工具会向提供的 URL 发起服务器端请求，并会阻止访问私有网络目标。请避免在 URL 中包含敏感信息（例如查询字符串中的令牌），并优先使用您信任的公共端点。

Pro Tips

Security Tip

优先使用受信任来源的白名单，而不是反射任何 Origin。应将 CORS 视为安全敏感的配置。

Security Tip

如果您使用 Cookie/身份验证，请设置 Access-Control-Allow-Credentials: true 并返回一个明确的来源（而不是 "*"）。

Security Tip

当允许多个来源或动态选择允许的来源时，请添加 Vary: Origin。

Performance Tip

为稳定的 API 设置合理的 Access-Control-Max-Age 以减少预检请求的延迟。

Best Practice

同时测试预检请求和实际请求路径；某些配置对 GET 返回正确的响应头，但对 OPTIONS 请求失败。

CI Tip

导出 JSON 报告，并将其与 API 网关配置更改一起保存，以便快速发现回归问题。

Additional Resources

CORS 指南 (MDN)
Reference
Access-Control-Allow-Origin (MDN)
Documentation
Access-Control-Allow-Credentials (MDN)
Documentation
Access-Control-Allow-Methods (MDN)
Documentation
Access-Control-Allow-Headers (MDN)
Documentation
Access-Control-Max-Age (MDN)
Documentation
Vary 响应头 (MDN)
Documentation

Other Tools

CORS检查器 — 测试Access-Control-*头部与预检（OPTIONS） | Encode64