197 lines
9.1 KiB
JSON
197 lines
9.1 KiB
JSON
|
{
|
|||
|
|
"topic": "cors",
|
|||
|
|
"type": "fill_blank",
|
|||
|
|
"schema_version": "1.0.0",
|
|||
|
|
"generated": "2026-09-02T21:20:00+08:00",
|
|||
|
|
"questions": [
|
|||
|
|
{
|
|||
|
|
"id": "fb-001",
|
|||
|
|
"type": "fill_blank",
|
|||
|
|
"difficulty": 2,
|
|||
|
|
"tags": [
|
|||
|
|
"CORS",
|
|||
|
|
"同源策略",
|
|||
|
|
"浏览器安全"
|
|||
|
|
],
|
|||
|
|
"question": "浏览器的同源策略通过比较 URL 的____三元组来判断两个源是否相同，这三个要素分别是协议、域名和____。",
|
|||
|
|
"answer": [
|
|||
|
|
"协议",
|
|||
|
|
"端口"
|
|||
|
|
],
|
|||
|
|
"answer_rule": "all",
|
|||
|
|
"explanation": "同源策略（Same-Origin Policy）是浏览器的核心安全机制。'同源'指的是两个 URL 的协议（如 http/https）、域名（如 example.com）和端口（如 80/443）三者完全一致。只要其中任意一个不同，浏览器就认为是跨源请求，会限制脚本对跨源资源的访问。",
|
|||
|
|
"source": null,
|
|||
|
|
"related": []
|
|||
|
|
},
|
|||
|
|
{
|
|||
|
|
"id": "fb-002",
|
|||
|
|
"type": "fill_blank",
|
|||
|
|
"difficulty": 2,
|
|||
|
|
"tags": [
|
|||
|
|
"CORS",
|
|||
|
|
"Origin",
|
|||
|
|
"跨源请求"
|
|||
|
|
],
|
|||
|
|
"question": "CORS（跨源资源共享）中，浏览器在跨源请求头中自动添加____字段，其值由协议、域名和端口组成，用于告知服务器请求来源。",
|
|||
|
|
"answer": [
|
|||
|
|
"Origin"
|
|||
|
|
],
|
|||
|
|
"answer_rule": "all",
|
|||
|
|
"explanation": "Origin 是浏览器在发起跨源请求时自动附加的 HTTP 头字段，格式为 \"scheme://host:port\"（如 \"http://localhost:3000\"）。服务器通过读取该字段来决定是否允许该跨源请求。注意 Origin 不包含路径信息，这是出于隐私考虑。",
|
|||
|
|
"source": null,
|
|||
|
|
"related": []
|
|||
|
|
},
|
|||
|
|
{
|
|||
|
|
"id": "fb-003",
|
|||
|
|
"type": "fill_blank",
|
|||
|
|
"difficulty": 3,
|
|||
|
|
"tags": [
|
|||
|
|
"CORS",
|
|||
|
|
"预检请求",
|
|||
|
|
"OPTIONS"
|
|||
|
|
],
|
|||
|
|
"question": "对于非简单请求，浏览器会先自动发送一个____方法的预检请求（Preflight Request），服务器返回允许的跨源策略后，浏览器才会发出真正的请求。",
|
|||
|
|
"answer": [
|
|||
|
|
"OPTIONS"
|
|||
|
|
],
|
|||
|
|
"answer_rule": "all",
|
|||
|
|
"explanation": "预检请求（Preflight Request）使用 HTTP OPTIONS 方法，在实际请求之前发送。它携带 Access-Control-Request-Method 和 Access-Control-Request-Headers 告知服务器即将发起的跨源请求信息。服务器通过响应头告知浏览器是否允许该请求，从而避免不安全的跨源请求到达服务器。",
|
|||
|
|
"source": null,
|
|||
|
|
"related": []
|
|||
|
|
},
|
|||
|
|
{
|
|||
|
|
"id": "fb-004",
|
|||
|
|
"type": "fill_blank",
|
|||
|
|
"difficulty": 3,
|
|||
|
|
"tags": [
|
|||
|
|
"CORS",
|
|||
|
|
"简单请求",
|
|||
|
|
"预检请求"
|
|||
|
|
],
|
|||
|
|
"question": "满足以下条件的请求属于简单请求：方法为 GET、____ 或 DELETE，且请求头仅包含 CORS 安全列表字段（如 Accept、Content-Type 限于 text/plain、multipart/form-data、application/x-www-form-urlencoded）。",
|
|||
|
|
"answer": [
|
|||
|
|
"POST",
|
|||
|
|
"PUT"
|
|||
|
|
],
|
|||
|
|
"answer_rule": "any",
|
|||
|
|
"explanation": "简单请求（Simple Request）不需要预检，浏览器直接发送并附带 Origin 头。判定标准：①方法为 GET、HEAD 或 POST（注意不是 PUT/DELETE）；②Content-Type 只限于 text/plain、multipart/form-data、application/x-www-form-urlencoded 三者之一；③没有自定义请求头。不满足任何一条都会触发预检。",
|
|||
|
|
"source": null,
|
|||
|
|
"related": []
|
|||
|
|
},
|
|||
|
|
{
|
|||
|
|
"id": "fb-005",
|
|||
|
|
"type": "fill_blank",
|
|||
|
|
"difficulty": 4,
|
|||
|
|
"tags": [
|
|||
|
|
"CORS",
|
|||
|
|
"Cookie",
|
|||
|
|
"Access-Control-Allow-Credentials"
|
|||
|
|
],
|
|||
|
|
"question": "当服务器响应 Access-Control-Allow-Origin 设置为通配符 * 时，____设置为 true 将不生效，浏览器会拒绝携带 Cookie 的跨源请求。",
|
|||
|
|
"answer": [
|
|||
|
|
"Access-Control-Allow-Credentials",
|
|||
|
|
"allowCredentials"
|
|||
|
|
],
|
|||
|
|
"answer_rule": "any",
|
|||
|
|
"explanation": "CORS 规范明确禁止在携带凭据（credentials）时使用通配符 *。当请求附带 Cookie（fetch 的 credentials: 'include' 或 XMLHttpRequest 的 withCredentials = true）时，服务器必须将 Access-Control-Allow-Origin 设置为具体的 Origin 值（不能是 *），同时将 Access-Control-Allow-Credentials 设为 true。这是安全考量，防止任意来源都能携带用户凭据访问资源。",
|
|||
|
|
"source": null,
|
|||
|
|
"related": []
|
|||
|
|
},
|
|||
|
|
{
|
|||
|
|
"id": "fb-006",
|
|||
|
|
"type": "fill_blank",
|
|||
|
|
"difficulty": 2,
|
|||
|
|
"tags": [
|
|||
|
|
"CORS",
|
|||
|
|
"开发环境",
|
|||
|
|
"跨域"
|
|||
|
|
],
|
|||
|
|
"question": "前端开发时，如果前端运行在 localhost:3000，后端运行在 localhost:8080，由于____不同，浏览器会将其视为跨域请求。",
|
|||
|
|
"answer": [
|
|||
|
|
"端口",
|
|||
|
|
"port"
|
|||
|
|
],
|
|||
|
|
"answer_rule": "any",
|
|||
|
|
"explanation": "同源策略的三元组中，协议（都是 http）和域名（都是 localhost）相同，但端口号不同（3000 vs 8080），因此被判定为跨源。即使都在本机，浏览器依然严格执行同源策略。常见的解决方式包括开发代理（如 Vite 的 proxy 配置）或后端配置 CORS 头。",
|
|||
|
|
"source": null,
|
|||
|
|
"related": []
|
|||
|
|
},
|
|||
|
|
{
|
|||
|
|
"id": "fb-007",
|
|||
|
|
"type": "fill_blank",
|
|||
|
|
"difficulty": 3,
|
|||
|
|
"tags": [
|
|||
|
|
"CORS",
|
|||
|
|
"WebSocket"
|
|||
|
|
],
|
|||
|
|
"question": "WebSocket 协议本身不受 CORS 限制，但 WebSocket 握手阶段的 HTTP Upgrade 请求会受到____策略的影响，浏览器可能会拒绝握手。",
|
|||
|
|
"answer": [
|
|||
|
|
"同源",
|
|||
|
|
"CORS",
|
|||
|
|
"同源策略"
|
|||
|
|
],
|
|||
|
|
"answer_rule": "any",
|
|||
|
|
"explanation": "WebSocket 连接通过 HTTP Upgrade 机制建立，浏览器在发起 WebSocket 握手时会检查目标 URL 是否符合 CORS 策略。如果服务器没有在响应中返回合适的 Access-Control-Allow-Origin 头，某些浏览器可能拒绝握手。不过一旦 WebSocket 连接建立成功，后续的数据帧传输完全不受 CORS 限制，这与 HTTP 请求的 CORS 机制有本质区别。",
|
|||
|
|
"source": null,
|
|||
|
|
"related": []
|
|||
|
|
},
|
|||
|
|
{
|
|||
|
|
"id": "fb-008",
|
|||
|
|
"type": "fill_blank",
|
|||
|
|
"difficulty": 3,
|
|||
|
|
"tags": [
|
|||
|
|
"CORS",
|
|||
|
|
"Nginx",
|
|||
|
|
"反向代理"
|
|||
|
|
],
|
|||
|
|
"question": "生产环境中常用的跨域解决方案是通过 Nginx 配置____，让前端和后端请求走同一个域名的同一端口，由 Nginx 在服务端转发请求。",
|
|||
|
|
"answer": [
|
|||
|
|
"反向代理",
|
|||
|
|
"reverse proxy"
|
|||
|
|
],
|
|||
|
|
"answer_rule": "any",
|
|||
|
|
"explanation": "Nginx 反向代理是解决跨域的生产级方案。原理：前端请求统一发到 Nginx（如 https://api.example.com），Nginx 根据 location 规则将 /api/* 的请求代理到实际后端服务。因为浏览器只和 Nginx 通信，不存在跨源问题。相比 CORS 头方案，反向代理还有统一入口、负载均衡、SSL 终端等优势。配置示例：location /api/ { proxy_pass http://backend:8080/; }",
|
|||
|
|
"source": null,
|
|||
|
|
"related": []
|
|||
|
|
},
|
|||
|
|
{
|
|||
|
|
"id": "fb-009",
|
|||
|
|
"type": "fill_blank",
|
|||
|
|
"difficulty": 3,
|
|||
|
|
"tags": [
|
|||
|
|
"CORS",
|
|||
|
|
"Vite",
|
|||
|
|
"开发代理"
|
|||
|
|
],
|
|||
|
|
"question": "Vite 开发服务器中通过 server.proxy 配置反向代理时，需要设置 ____: true 使得代理请求的 Host 头与目标服务器一致，避免目标服务器返回错误。",
|
|||
|
|
"answer": [
|
|||
|
|
"changeOrigin",
|
|||
|
|
"change_origin"
|
|||
|
|
],
|
|||
|
|
"answer_rule": "any",
|
|||
|
|
"explanation": "Vite 的开发代理基于 http-proxy-middleware。changeOrigin: true 会将请求头中的 Host 字段修改为目标服务器的 host，这样目标服务器收到的请求就像直接发给自己一样。例如前端请求 localhost:3000/api/users，代理到 backend:8080，如果不开 changeOrigin，Host 头仍是 localhost:3000，后端可能无法正确路由。配置示例：proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } }",
|
|||
|
|
"source": null,
|
|||
|
|
"related": []
|
|||
|
|
},
|
|||
|
|
{
|
|||
|
|
"id": "fb-010",
|
|||
|
|
"type": "fill_blank",
|
|||
|
|
"difficulty": 4,
|
|||
|
|
"tags": [
|
|||
|
|
"CORS",
|
|||
|
|
"CSRF",
|
|||
|
|
"同源策略",
|
|||
|
|
"安全"
|
|||
|
|
],
|
|||
|
|
"question": "同源策略在安全方面的一个重要作用是防止____攻击：恶意网站无法直接读取用户在银行网站的 Cookie，因此无法伪造合法请求来冒充用户向银行服务器发送转账指令。",
|
|||
|
|
"answer": [
|
|||
|
|
"CSRF",
|
|||
|
|
"跨站请求伪造"
|
|||
|
|
],
|
|||
|
|
"answer_rule": "any",
|
|||
|
|
"explanation": "CSRF（Cross-Site Request Forgery，跨站请求伪造）是一种利用用户已登录状态发起恶意请求的攻击。虽然同源策略能阻止恶意网站读取银行网站的响应数据，但仅靠同源策略并不能完全防御 CSRF——因为同源策略只限制'读'，不完全限制'写'（如表单提交、图片标签等仍可触发跨源请求）。完整防御 CSRF 还需要 CSRF Token、SameSite Cookie 属性等额外机制。同源策略是第一道防线，但不是唯一防线。",
|
|||
|
|
"source": null,
|
|||
|
|
"related": []
|
|||
|
|
}
|
|||
|
|
]
|
|||
|
|
}
|