跨域与资源安全：前端开发必知的安全知识

引言

在当今互联网世界中，Web安全已经成为每个前端开发者必须掌握的核心技能。想象一下，你正在打造一个精美的网站，却忽略了基本的安全防护，这就像是建造了一座华丽的房子，却忘记安装门锁——任何人都可以轻易闯入。

本文将带你深入了解跨域安全与资源防护的核心概念，这些知识不仅能帮助你解决开发中的常见问题，更能让你的应用变得更加安全可靠。我们会用通俗易懂的语言，配合实用的代码示例，让你轻松掌握这些看似复杂的安全概念。

同源策略与跨域问题：浏览器的安全基石

同源策略：网络世界的"边境管控"

同源策略(Same-Origin Policy)是浏览器安全的基础，它限制了一个源(origin)的文档或脚本如何与另一个源的资源进行交互。简单来说，它就像是国家之间的边境管控，确保不同"国家"(网站)之间的资源不能随意互通。

什么是"同源"？两个URL必须满足三个条件才算同源：

相同的协议（如都是https）
相同的域名（如都是example.com）
相同的端口（如都是443）

javascript

// 以下URL与 https://example.com 的同源比较
https://example.com/page1.html         // ✓ 同源
https://example.com/subdirectory/page.html  // ✓ 同源
http://example.com                    // ✗ 协议不同
https://sub.example.com               // ✗ 子域名不同
https://example.com:8080              // ✗ 端口不同

为什么浏览器要实施同源策略？试想一下，如果没有这个限制：

恶意网站可以读取你的Gmail邮件内容
钓鱼网站可以获取你在银行网站的账户信息
攻击者可以操纵你访问过的其他网站

跨域访问限制的具体表现

同源策略对不同资源的限制程度是不同的：

javascript

// 在 https://myapp.com 下尝试访问 https://api.myapp.com 的Cookie
// 这将被阻止！
document.cookie = "token=abc123; domain=api.myapp.com"; // 不起作用

浏览器的存储机制(Cookie, LocalStorage等)是严格遵循同源策略的，一个源的JavaScript无法读取或写入另一个源的存储数据。

2. DOM操作限制

javascript

// 在 https://myapp.com 下尝试访问嵌入的 https://othersite.com iframe内容
const iframe = document.querySelector('iframe');
// 这将抛出错误！
console.log(iframe.contentDocument); // 错误：无法访问跨域iframe的内容

当一个网页嵌入了不同源的iframe，父页面的JavaScript无法访问iframe的DOM结构。

3. Ajax请求限制

javascript

// 在 https://myapp.com 下尝试请求 https://api.othersite.com 的数据
fetch('https://api.othersite.com/data')
  .then(response => response.json())
  .catch(error => console.error('跨域请求被阻止:', error));

这是前端开发中遇到最多的跨域问题——默认情况下，Ajax请求只能发送到同源的服务器。

为什么现代Web应用需要跨域？

随着Web应用架构的发展，跨域需求越来越普遍：

用户 → 前端应用(app.example.com)
                ↓
       API服务(api.example.com)
                ↓
       数据库服务(内部网络)

现代前端应用通常采用前后端分离架构：

前端应用部署在专用服务器或CDN上
后端API可能部署在不同的域名下
微前端架构中，不同子应用可能分布在不同域名
需要集成第三方服务（支付、地图、社交分享等）

所以我们需要安全的跨域解决方案，既能打破必要的限制，又能保持基本的安全防护。

解决跨域问题的实用技术

JSONP：古老但实用的跨域技术

JSONP（JSON with Padding）是一种利用<script>标签不受同源策略限制的特性实现跨域的技术。

javascript

// JSONP的基本实现
function handleResponse(data) {
  console.log('获取的数据:', data);
}

// 创建script标签
const script = document.createElement('script');
script.src = 'https://api.example.com/data?callback=handleResponse';
document.body.appendChild(script);

// 服务端会返回如下内容：
// handleResponse({"name": "张三", "age": 30});

JSONP的工作原理：

客户端定义一个全局回调函数
通过动态创建<script>标签，请求跨域服务器的资源
服务器返回这个回调函数的调用，并将数据作为参数
浏览器执行返回的JavaScript，调用回调函数

优点：

兼容性好，支持几乎所有浏览器
简单易用，无需复杂配置

缺点：

只支持GET请求
存在安全风险，如可能遭受XSS攻击
没有标准的错误处理机制

javascript

// jQuery中使用JSONP的例子
$.ajax({
  url: 'https://api.example.com/data',
  dataType: 'jsonp',
  success: function(data) {
    console.log('成功获取数据:', data);
  }
});

代理服务器：规避跨域问题

由于同源策略是浏览器强制执行的安全机制，服务器之间的通信不受此限制。因此，我们可以通过自己的服务器作为中介来规避跨域问题。

浏览器 → 同源代理服务器 → 目标跨域资源

1. 开发环境：使用webpack-dev-server代理

在React、Vue等项目的开发环境中，可以轻松配置代理：

javascript

// React项目中的代理配置(package.json)
{
  "proxy": "https://api.example.com"
}

// Vue项目中的代理配置(vue.config.js)
module.exports = {
  devServer: {
    proxy: {
      '/api': {
        target: 'https://api.example.com',
        changeOrigin: true
      }
    }
  }
}

使用代理后，前端代码可以像请求同源资源一样简单：

javascript

// 原本需要请求：https://api.example.com/users
// 现在只需请求本地路径
fetch('/api/users')
  .then(response => response.json())
  .then(data => console.log(data));

2. 生产环境：Nginx反向代理

在生产环境中，可以使用Nginx设置反向代理：

nginx

# Nginx配置示例
server {
    listen 80;
    server_name myapp.com;
    
    # 静态资源
    location / {
        root /var/www/html;
        index index.html;
    }
    
    # API代理
    location /api/ {
        proxy_pass https://api.example.com/;
        proxy_set_header Host api.example.com;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

代理方案的优点：

完全规避浏览器的同源策略
可以隐藏敏感的API地址
可以在代理层进行额外的安全过滤

缺点：

需要服务器资源和配置
增加了请求的处理环节

CORS：规范化的跨域资源共享

CORS（Cross-Origin Resource Sharing，跨域资源共享）是W3C标准，是现代浏览器支持的跨域解决方案。与JSONP相比，CORS更加灵活和安全。

CORS的工作原理简介

CORS通过一系列HTTP头部字段，允许服务器声明哪些源可以访问哪些资源。浏览器会自动处理这些头部，执行必要的检查。

浏览器 → 发送带Origin头的请求 → 服务器
浏览器 ← 检查响应头中的CORS权限 ← 服务器返回带CORS头的响应

简单请求与预检请求

CORS将请求分为两类：简单请求和需要预检的请求。

简单请求条件：

一个请求满足以下所有条件，就属于简单请求：

使用GET、POST或HEAD方法
只包含简单头部（如Accept、Content-Type等）
Content-Type只能是：
- text/plain
- multipart/form-data
- application/x-www-form-urlencoded

简单请求的流程：

浏览器 → 发送请求(带Origin头) → 服务器
浏览器 ← 检查CORS响应头 ← 服务器返回响应(带CORS头)

需要预检的请求：

不满足简单请求条件的，都需要先发送预检请求：

javascript

// 需要预检的请求例子
fetch('https://api.example.com/data', {
  method: 'PUT', // 非简单方法
  headers: {
    'Content-Type': 'application/json', // 复杂Content-Type
    'X-Custom-Header': 'value' // 自定义头部
  },
  body: JSON.stringify({name: '张三'})
});

预检请求流程：

浏览器 → 发送OPTIONS预检请求 → 服务器
浏览器 ← 检查预检响应中的CORS权限 ← 服务器返回预检响应
// 如果预检通过，才发送实际请求
浏览器 → 发送实际请求 → 服务器
浏览器 ← 接收实际响应 ← 服务器

重要的CORS响应头

1. Access-Control-Allow-Origin

指定允许哪些源访问资源：

http

// 允许特定源
Access-Control-Allow-Origin: https://myapp.com

// 允许任意源（公开API常用）
Access-Control-Allow-Origin: *

2. Access-Control-Allow-Methods

指定允许的HTTP方法：

http

Access-Control-Allow-Methods: GET, POST, PUT, DELETE

3. Access-Control-Allow-Headers

指定允许的请求头：

http

Access-Control-Allow-Headers: Content-Type, Authorization, X-Requested-With

4. Access-Control-Allow-Credentials

是否允许发送Cookie等凭证：

http

Access-Control-Allow-Credentials: true

当使用此配置时，前端也需要设置：

javascript

// 使用fetch
fetch('https://api.example.com/user-data', {
  credentials: 'include' // 包含凭证
})

// 使用XMLHttpRequest
const xhr = new XMLHttpRequest();
xhr.withCredentials = true;

安全提示：设置credentials: true时，Access-Control-Allow-Origin不能为通配符，必须明确指定源。

5. Access-Control-Max-Age

预检请求的缓存时间（秒）：

http

Access-Control-Max-Age: 86400 // 缓存24小时

常见服务器CORS配置示例

Express.js (Node.js) 配置

javascript

// 使用cors中间件
const express = require('express');
const cors = require('cors');
const app = express();

// 简单配置：允许所有源
app.use(cors());

// 自定义配置
app.use(cors({
  origin: ['https://myapp.com', 'https://admin.myapp.com'],
  methods: ['GET', 'POST', 'PUT'],
  allowedHeaders: ['Content-Type', 'Authorization'],
  credentials: true,
  maxAge: 86400
}));

Spring Boot (Java) 配置

java

@Configuration
public class WebConfig implements WebMvcConfigurer {
    
    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/api/**")
            .allowedOrigins("https://myapp.com")
            .allowedMethods("GET", "POST", "PUT")
            .allowedHeaders("Content-Type", "Authorization")
            .allowCredentials(true)
            .maxAge(3600);
    }
}

Nginx配置

nginx

server {
    # ...
    
    location /api/ {
        # CORS设置
        add_header 'Access-Control-Allow-Origin' 'https://myapp.com';
        add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';
        add_header 'Access-Control-Allow-Headers' 'DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Authorization';
        
        # 处理OPTIONS预检请求
        if ($request_method = 'OPTIONS') {
            add_header 'Access-Control-Max-Age' 1728000;
            add_header 'Content-Type' 'text/plain charset=UTF-8';
            add_header 'Content-Length' 0;
            return 204;
        }
        
        proxy_pass http://backend-server;
    }
}

内容安全策略（CSP）：防御XSS的强力武器

内容安全策略（Content Security Policy，CSP）是一种额外的安全层，帮助检测并缓解某些类型的攻击，特别是跨站脚本攻击（XSS）和数据注入攻击。

CSP的基本概念与工作原理

CSP通过指定哪些内容源是被授权的，告诉浏览器只执行或渲染来自这些可信来源的资源，从而防止恶意代码的执行。

html

<!-- 通过HTTP头部启用CSP -->
<!-- 服务器返回的响应头 -->
Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted-cdn.com

<!-- 或通过meta标签启用 -->
<meta http-equiv="Content-Security-Policy" content="default-src 'self'; script-src 'self' https://trusted-cdn.com">

上面的配置告诉浏览器：

默认情况下，只加载来自当前域的资源
JavaScript脚本只允许从当前域和trusted-cdn.com加载

CSP主要指令详解

CSP提供了多种指令来控制不同类型资源的加载：

default-src：默认资源控制

default-src 'self';

这是一个备用指令，当某类资源没有专门的指令时，使用这个默认值。'self'表示只允许来自同源的资源。

script-src：脚本资源控制

script-src 'self' https://trusted-cdn.com 'nonce-RandomString';

控制JavaScript的加载来源。可以使用：

域名：如trusted-cdn.com
'self'：当前域
'unsafe-inline'：允许内联脚本（不推荐）
'unsafe-eval'：允许eval()（不推荐）
'nonce-xxx'：带有特定nonce值的脚本允许执行

style-src：样式资源控制

style-src 'self' https://fonts.googleapis.com;

控制CSS的加载来源，选项与script-src类似。

img-src、font-src、connect-src等

分别控制图片、字体和Ajax/WebSocket等连接的来源。

img-src 'self' https://img.example.com;
font-src github.githubassets.com;
connect-src 'self' https://api.example.com;

CSP部署策略：从宽松到严格

CSP部署可以从报告模式开始，逐步加强：

1. 报告模式（Report-Only）

Content-Security-Policy-Report-Only: default-src 'self'; report-uri /csp-report

只报告违规，不阻止资源加载，适合初期测试使用。

2. 基本保护模式

Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted-cdn.com

允许来自特定可信来源的资源。

3. 严格模式

Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'

限制所有外部资源，只允许同源资源加载。

CSP实施案例分析

大型网站如GitHub、Twitter等都使用CSP防御XSS攻击。以GitHub的CSP配置为例：

default-src 'none';
base-uri 'self';
block-all-mixed-content;
connect-src 'self' uploads.github.com www.githubstatus.com collector.githubapp.com
api.github.com github-cloud.s3.amazonaws.com github-production-repository-file-5c1aeb.s3.amazonaws.com
github-production-upload-manifest-file-7fdce7.s3.amazonaws.com github-production-user-asset-6210df.s3.amazonaws.com
html-translator.githubusercontent.com wss://alive.github.com;
font-src github.githubassets.com;
form-action 'self' github.com gist.github.com;
...

其他跨域技术：解决特殊场景的需求

除了CORS和JSONP，还有一些特殊场景下的跨域解决方案。

postMessage：跨窗口通信的安全方式

window.postMessage是一种控制不同窗口（如iframe、弹窗）之间进行跨域通信的安全方法。

javascript

// 在父窗口中向iframe发送消息
const iframe = document.querySelector('iframe');
iframe.contentWindow.postMessage('你好，我是父窗口', 'https://iframe-domain.com');

// 在iframe中接收消息
window.addEventListener('message', function(event) {
  // 始终验证消息来源
  if (event.origin !== 'https://parent-domain.com') return;
  
  console.log('收到消息：', event.data);
  
  // 回复消息
  event.source.postMessage('收到了，这是回复', event.origin);
});

安全提示：

始终指定确切的targetOrigin，避免使用*
接收消息时验证event.origin来源
不要直接执行接收到的消息中的代码

WebSocket：全双工跨域通信

WebSocket是一种在单个TCP连接上进行全双工通信的协议，它天然支持跨域通信。

javascript

// 建立WebSocket连接
const socket = new WebSocket('wss://api.example.com/socket');

// 监听连接打开事件
socket.addEventListener('open', function(event) {
  socket.send('你好，服务器');
});

// 监听消息接收事件
socket.addEventListener('message', function(event) {
  console.log('收到服务器消息：', event.data);
});

// 监听连接关闭事件
socket.addEventListener('close', function(event) {
  console.log('连接已关闭');
});

WebSocket优势：

全双工通信，服务器可以主动推送数据
较少的控制开销，数据传输高效
没有同源策略限制
支持二进制数据传输

iframe跨域通信技术

在某些需要嵌入第三方内容的场景下，iframe是常用的解决方案。以下是几种iframe跨域通信方法：

document.domain：适用于子域名通信

如果页面和嵌套的iframe来自同一主域的不同子域，可以通过设置相同的document.domain来实现通信。

javascript

// 在 https://app.example.com 页面中
document.domain = 'example.com';

// 在 https://widget.example.com 的iframe中
document.domain = 'example.com';

// 此时两个页面可以直接访问彼此的变量和方法

注意：此方法只适用于主域相同的情况。

location.hash：传递简单数据

利用URL片段标识符(hash)在不同域的frame之间传递信息：

javascript

// 父页面向iframe传递数据
iframe.src = iframe.src + '#message=' + encodeURIComponent('Hello iframe');

// iframe监听hash变化
window.onhashchange = function() {
  const message = decodeURIComponent(location.hash.substr(9)); // 去掉 #message=
  console.log('收到消息:', message);
  
  // 回复消息给父页面
  parent.location.hash = '#reply=' + encodeURIComponent('Got it!');
};

这种方法适合传递少量数据，但不够优雅。

window.name：共享持久数据

window.name属性在页面跳转后仍然保持不变，可以用于跨域传递数据：

javascript

// iframe中设置数据
window.name = JSON.stringify({message: "这是共享的数据"});

父页面可以在iframe加载完成后访问其window.name属性获取数据。

资源完整性与子资源安全：防止资源被篡改

在引用外部资源（特别是第三方CDN上的脚本和样式）时，如何确保这些资源没有被篡改是一个重要的安全问题。

子资源完整性(SRI)：验证资源未被篡改

SRI(Subresource Integrity)允许浏览器检查获取的资源是否被篡改，通过提供资源的加密哈希值实现。

html

<script src="https://cdn.example.com/library.js"
        integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
        crossorigin="anonymous"></script>

当浏览器下载此脚本后，会计算其哈希值并与integrity属性提供的值比较。如果不匹配，浏览器将拒绝执行此脚本。

生成integrity值的方法：

bash

# 使用sha384算法生成哈希值
openssl dgst -sha384 -binary library.js | openssl base64 -A

资源引用安全策略：控制请求来源信息

1. Referrer-Policy：控制请求头中的来源信息

当从一个页面导航到另一个页面或加载子资源时，浏览器会发送Referer头，表明请求来自哪个页面。这可能会泄露敏感信息。

html

<!-- 通过HTTP头控制 -->
Referrer-Policy: no-referrer-when-downgrade

<!-- 或通过meta标签控制 -->
<meta name="referrer" content="strict-origin">

常用的策略值：

no-referrer：不发送Referer头
no-referrer-when-downgrade：仅在HTTPS→HTTP降级时不发送
origin：只发送源（协议、域名、端口），不包含路径
strict-origin：只在同等安全级别（HTTPS→HTTPS）发送源

2. rel="noopener noreferrer"：保护链接安全

当使用target="_blank"打开新窗口时，新页面可以通过window.opener访问原页面的window对象，这是一个潜在的安全风险。

html

<!-- 安全的外部链接写法 -->
<a href="https://external-site.com" target="_blank" rel="noopener noreferrer">外部链接</a>

rel="noopener"阻止新页面访问window.opener属性，rel="noreferrer"阻止传递Referer信息。

3. X-Content-Type-Options：防止MIME类型嗅探

浏览器有时会"嗅探"内容的实际类型，这可能被利用来执行伪装的脚本文件。

X-Content-Type-Options: nosniff

此响应头告诉浏览器完全遵守Content-Type头指定的MIME类型，不要尝试猜测。

安全加载第三方资源的最佳实践

优先使用HTTPS资源

html

<!-- 避免 -->
<script src="http://cdn.example.com/script.js"></script>

<!-- 推荐 -->
<script src="https://cdn.example.com/script.js"></script>

实施SRI验证 对所有外部脚本和样式使用integrity属性。

限制第三方库权限

html

<!-- 对不需要cookie的资源添加crossorigin属性 -->
<link rel="stylesheet" href="https://cdn.example.com/style.css" crossorigin="anonymous">

定期审计第三方代码 了解引入的第三方库的功能和潜在风险。
考虑自托管关键资源 对于关键业务功能依赖的资源，考虑自己托管而非依赖第三方CDN。

总结：构建安全可靠的前端应用

Web安全是一个复杂且持续发展的领域，作为前端开发者，了解跨域安全和资源保护的基本原则至关重要：

理解同源策略的核心意义：它是浏览器安全的基石，限制了跨源访问以保护用户数据。
选择合适的跨域解决方案：
- 简单数据获取：CORS是最佳选择
- 需要兼容旧浏览器：可以考虑JSONP
- 复杂场景：服务器代理可能是更好的解决方案
- 实时通信：WebSocket天然支持跨域
实施内容安全策略(CSP)：这是抵御XSS攻击的强大工具，应根据应用需求配置合适的策略。
保护资源完整性：对外部资源使用SRI，确保不被恶意篡改。
持续学习和更新安全知识：Web安全领域不断发展，定期了解最新的安全最佳实践。

记住，安全不是一次性的工作，而是一个持续的过程。通过合理实施本文介绍的安全机制，你可以构建既满足功能需求，又能保护用户数据安全的现代Web应用。

拓展阅读

希望本文能帮助你更好地理解Web安全的基本概念，构建更加安全可靠的前端应用！

跨域与资源安全：前端开发必知的安全知识 ​

引言 ​

同源策略与跨域问题：浏览器的安全基石 ​

同源策略：网络世界的"边境管控" ​

跨域访问限制的具体表现 ​

1. Cookie、LocalStorage和IndexedDB访问限制 ​

2. DOM操作限制 ​

3. Ajax请求限制 ​

为什么现代Web应用需要跨域？ ​

解决跨域问题的实用技术 ​

JSONP：古老但实用的跨域技术 ​

代理服务器：规避跨域问题 ​

1. 开发环境：使用webpack-dev-server代理 ​

2. 生产环境：Nginx反向代理 ​

CORS：规范化的跨域资源共享 ​

CORS的工作原理简介 ​

简单请求与预检请求 ​

简单请求条件： ​

需要预检的请求： ​

重要的CORS响应头 ​

1. Access-Control-Allow-Origin ​

2. Access-Control-Allow-Methods ​

3. Access-Control-Allow-Headers ​

4. Access-Control-Allow-Credentials ​

5. Access-Control-Max-Age ​

常见服务器CORS配置示例 ​

Express.js (Node.js) 配置 ​

Spring Boot (Java) 配置 ​

Nginx配置 ​

内容安全策略（CSP）：防御XSS的强力武器 ​

CSP的基本概念与工作原理 ​

CSP主要指令详解 ​

default-src：默认资源控制 ​

script-src：脚本资源控制 ​

style-src：样式资源控制 ​

img-src、font-src、connect-src等 ​

CSP部署策略：从宽松到严格 ​

1. 报告模式（Report-Only） ​

2. 基本保护模式 ​

3. 严格模式 ​

CSP实施案例分析 ​

其他跨域技术：解决特殊场景的需求 ​

postMessage：跨窗口通信的安全方式 ​

WebSocket：全双工跨域通信 ​

iframe跨域通信技术 ​

document.domain：适用于子域名通信 ​

location.hash：传递简单数据 ​

window.name：共享持久数据 ​

资源完整性与子资源安全：防止资源被篡改 ​

子资源完整性(SRI)：验证资源未被篡改 ​

资源引用安全策略：控制请求来源信息 ​

1. Referrer-Policy：控制请求头中的来源信息 ​

2. rel="noopener noreferrer"：保护链接安全 ​

3. X-Content-Type-Options：防止MIME类型嗅探 ​

安全加载第三方资源的最佳实践 ​

总结：构建安全可靠的前端应用 ​

拓展阅读 ​

跨域与资源安全：前端开发必知的安全知识

引言

同源策略与跨域问题：浏览器的安全基石

同源策略：网络世界的"边境管控"

跨域访问限制的具体表现

1. Cookie、LocalStorage和IndexedDB访问限制

2. DOM操作限制

3. Ajax请求限制

为什么现代Web应用需要跨域？

解决跨域问题的实用技术

JSONP：古老但实用的跨域技术

代理服务器：规避跨域问题

1. 开发环境：使用webpack-dev-server代理

2. 生产环境：Nginx反向代理

CORS：规范化的跨域资源共享

CORS的工作原理简介

简单请求与预检请求

简单请求条件：

需要预检的请求：

重要的CORS响应头

1. Access-Control-Allow-Origin

2. Access-Control-Allow-Methods

3. Access-Control-Allow-Headers

4. Access-Control-Allow-Credentials

5. Access-Control-Max-Age

常见服务器CORS配置示例

Express.js (Node.js) 配置

Spring Boot (Java) 配置

Nginx配置

内容安全策略（CSP）：防御XSS的强力武器

CSP的基本概念与工作原理

CSP主要指令详解

default-src：默认资源控制

script-src：脚本资源控制

style-src：样式资源控制

img-src、font-src、connect-src等

CSP部署策略：从宽松到严格

1. 报告模式（Report-Only）

2. 基本保护模式

3. 严格模式

CSP实施案例分析

其他跨域技术：解决特殊场景的需求

postMessage：跨窗口通信的安全方式

WebSocket：全双工跨域通信

iframe跨域通信技术

document.domain：适用于子域名通信

location.hash：传递简单数据

window.name：共享持久数据

资源完整性与子资源安全：防止资源被篡改

子资源完整性(SRI)：验证资源未被篡改

资源引用安全策略：控制请求来源信息

1. Referrer-Policy：控制请求头中的来源信息

2. rel="noopener noreferrer"：保护链接安全

3. X-Content-Type-Options：防止MIME类型嗅探

安全加载第三方资源的最佳实践

总结：构建安全可靠的前端应用

拓展阅读