同源策略与前端跨域

最新推荐文章于 2024-09-24 08:00:00 发布
最新推荐文章于 2024-09-24 08:00:00 发布
阅读量1.6k 收藏 4
点赞数
分类专栏： 网络知识

原文链接：https://segmentfault.com/a/1190000015597029 

同源策略在web应用的安全模型中是一个重要概念。在这个策略下，web浏览器允许第一个页面的脚本访问第二个页面里的数据，但是也只有在两个页面有相同的源时。源是由URI，主机名，端口号组合而成的。这个策略可以阻止一个页面上的恶意脚本通过页面的DOM对象获得访问另一个页面上敏感信息的权限。

对于普遍依赖于cookie维护授权用户session的现代浏览器来说，这种机制有特殊意义。客户端必须在不同站点提供的内容之间维持一个严格限制，以防丢失数据机密或者完整性。

历史

同源策略的概念要追溯到1995年的网景浏览器。同源策略作为一个重要的安全基石，所有的现代浏览器都在一定程度上实现了同源策略。同源策略虽然不是一个明确规范，但是经常为某些web技术（例如Microsoft Silverlight,Adobe Flash,Adobe Acrobat）或者某些机制（例如XMLHttpRequest）扩展定义大致兼容的安全边界。

源决定规则

RFC6454中有定义URI源的算法定义。对于绝对的URIs，源就是{协议，主机，端口}定义的。只有这些值完全一样才认为两个资源是同源的。

为了举例，下面的表格给出了与URL"http://www.example.com/dir/page.html"的对比。

对比URL结果结果
http://www.example.com/dir/page2.html同源相同的协议，主机，端口
http://www.example.com/dir2/other.html同源相同的协议，主机，端口
http://username:password@www.example.com/dir2/other.html同源相同的协议，主机，端口
http://www.example.com:81/dir/other.html不同源相同的协议，主机，端口不同
https://www.example.com/dir/other.html不同源协议不同
http://en.example.com/dir/other.html不同源不同主机
http://example.com/dir/other.html不同源不同主机(需要精确匹配)
http://v2.www.example.com/dir/other.html不同源不同主机(需要精确匹配)
http://www.example.com:80/dir/other.html看情况端口明确，依赖浏览器实现

不像其他浏览器，IE在计算源的时候没有包括端口。

 

没有同源策略限制的两大危险场景

浏览器是从两个方面去做这个同源策略的，一是针对接口的请求，二是针对Dom的查询。试想一下没有这样的限制上述两种动作有什么危险。

没有同源策略限制的接口请求

有一个小小的东西叫cookie大家应该知道，一般用来处理登录等场景，目的是让服务端知道谁发出的这次请求。如果你请求了接口进行登录，服务端验证通过后会在响应头加入Set-Cookie字段，然后下次再发请求的时候，浏览器会自动将cookie附加在HTTP请求的头字段Cookie中，服务端就能知道这个用户已经登录过了。知道这个之后，我们来看场景：
1.你准备去清空你的购物车，于是打开了买买买网站www.maimaimai.com，然后登录成功，一看，购物车东西这么少，不行，还得买多点。
2.你在看有什么东西买的过程中，你的好基友发给你一个链接www.nidongde.com，一脸yin笑地跟你说：“你懂的”，你毫不犹豫打开了。
3.你饶有兴致地浏览着www.nidongde.com，谁知这个网站暗地里做了些不可描述的事情！由于没有同源策略的限制，它向www.maimaimai.com发起了请求！聪明的你一定想到上面的话“服务端验证通过后会在响应头加入Set-Cookie字段，然后下次再发请求的时候，浏览器会自动将cookie附加在HTTP请求的头字段Cookie中”，这样一来，这个不法网站就相当于登录了你的账号，可以为所欲为了！如果这不是一个买买买账号，而是你的银行账号，那……
这就是传说中的CSRF攻击浅谈CSRF攻击方式。
看了这波CSRF攻击我在想，即使有了同源策略限制，但cookie是明文的，还不是一样能拿下来。于是我看了一些cookie相关的文章聊一聊 cookie、Cookie/Session的机制与安全，知道了服务端可以设置httpOnly，使得前端无法操作cookie，如果没有这样的设置，像XSS攻击就可以去获取到cookieWeb安全测试之XSS；设置secure，则保证在https的加密通信中传输以防截获。

没有同源策略限制的Dom查询

1.有一天你刚睡醒，收到一封邮件，说是你的银行账号有风险，赶紧点进www.yinghang.com改密码。你吓尿了，赶紧点进去，还是熟悉的银行登录界面，你果断输入你的账号密码，登录进去看看钱有没有少了。
2.睡眼朦胧的你没看清楚，平时访问的银行网站是www.yinhang.com，而现在访问的是www.yinghang.com，这个钓鱼网站做了什么呢？

// HTML
<iframe name="yinhang" src="www.yinhang.com"></iframe>
// JS
// 由于没有同源策略的限制，钓鱼网站可以直接拿到别的网站的Dom
const iframe = window.frames['yinhang']
const node = iframe.document.getElementById('你输入账号密码的Input')
console.log(`拿到了这个${node}，我还拿不到你刚刚输入的账号密码吗`)

由此我们知道，同源策略确实能规避一些危险，不是说有了同源策略就安全，只是说同源策略是一种浏览器最基本的安全机制，毕竟能提高一点攻击的成本。其实没有刺不穿的盾，只是攻击的成本和攻击成功后获得的利益成不成正比。

跨域正确的打开方式

经过对同源策略的了解，我们应该要消除对浏览器的误解，同源策略是浏览器做的一件好事，是用来防御来自邪门歪道的攻击，但总不能为了不让坏人进门而把全部人都拒之门外吧。没错，我们这种正人君子只要打开方式正确，就应该可以跨域。
下面将一个个演示正确打开方式，但在此之前，有些准备工作要做。为了本地演示跨域，我们需要：
1.随便跑起一份前端代码（以下前端是随便跑起来的vue），地址是http://localhost:9099。
2.随便跑起一份后端代码（以下后端是随便跑起来的node koa2），地址是http://localhost:9971。

同源策略限制下接口请求的正确打开方式

1.JSONP
在HTML标签里，一些标签比如script、img这样的获取资源的标签是没有跨域限制的，利用这一点，我们可以这样干：

后端写个小接口

// 处理成功失败返回格式的工具
const {successBody} = require('../utli')
class CrossDomain {
  static async jsonp (ctx) {
    // 前端传过来的参数
    const query = ctx.request.query
    // 设置一个cookies
    ctx.cookies.set('tokenId', '1')
    // query.cb是前后端约定的方法名字，其实就是后端返回一个直接执行的方法给前端，由于前端是用script标签发起的请求，所以返回了这个方法后相当于立马执行，并且把要返回的数据放在方法的参数里。
    ctx.body = `${query.cb}(${JSON.stringify(successBody({msg: query.msg}, 'success'))})`
  }
}
module.exports = CrossDomain

简单版前端

<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8">
  </head>
  <body>
    <script type='text/javascript'>
      // 后端返回直接执行的方法，相当于执行这个方法，由于后端把返回的数据放在方法的参数里，所以这里能拿到res。
      window.jsonpCb = function (res) {
        console.log(res)
      }
    </script>
    <script src='http://localhost:9871/api/jsonp?msg=helloJsonp&cb=jsonpCb' type='text/javascript'></script>
  </body>
</html>

简单封装一下前端这个套路

/**
 * JSONP请求工具
 * @param url 请求的地址
 * @param data 请求的参数
 * @returns {Promise<any>}
 */
const request = ({url, data}) => {
  return new Promise((resolve, reject) => {
    // 处理传参成xx=yy&aa=bb的形式
    const handleData = (data) => {
      const keys = Object.keys(data)
      const keysLen = keys.length
      return keys.reduce((pre, cur, index) => {
        const value = data[cur]
        const flag = index !== keysLen - 1 ? '&' : ''
        return `${pre}${cur}=${value}${flag}`
      }, '')
    }
    // 动态创建script标签
    const script = document.createElement('script')
    // 接口返回的数据获取
    window.jsonpCb = (res) => {
      document.body.removeChild(script)
      delete window.jsonpCb
      resolve(res)
    }
    script.src = `${url}?${handleData(data)}&cb=jsonpCb`
    document.body.appendChild(script)
  })
}
// 使用方式
request({
  url: 'http://localhost:9871/api/jsonp',
  data: {
    // 传参
    msg: 'helloJsonp'
  }
}).then(res => {
  console.log(res)
})

2.空iframe加form
细心的朋友可能发现，JSONP只能发GET请求，因为本质上script加载资源就是GET，那么如果要发POST请求怎么办呢？

后端写个小接口

// 处理成功失败返回格式的工具
const {successBody} = require('../utli')
class CrossDomain {
  static async iframePost (ctx) {
    let postData = ctx.request.body
    console.log(postData)
    ctx.body = successBody({postData: postData}, 'success')
  }
}
module.exports = CrossDomain

前端

const requestPost = ({url, data}) => {
  // 首先创建一个用来发送数据的iframe.
  const iframe = document.createElement('iframe')
  iframe.name = 'iframePost'
  iframe.style.display = 'none'
  document.body.appendChild(iframe)
  const form = document.createElement('form')
  const node = document.createElement('input')
  // 注册iframe的load事件处理程序,如果你需要在响应返回时执行一些操作的话.
  iframe.addEventListener('load', function () {
    console.log('post success')
  })

  form.action = url
  // 在指定的iframe中执行form
  form.target = iframe.name
  form.method = 'post'
  for (let name in data) {
    node.name = name
    node.value = data[name].toString()
    form.appendChild(node.cloneNode())
  }
  // 表单元素需要添加到主文档中.
  form.style.display = 'none'
  document.body.appendChild(form)
  form.submit()

  // 表单提交后,就可以删除这个表单,不影响下次的数据发送.
  document.body.removeChild(form)
}
// 使用方式
requestPost({
  url: 'http://localhost:9871/api/iframePost',
  data: {
    msg: 'helloIframePost'
  }
})

3.CORS

CORS是一个W3C标准，全称是"跨域资源共享"（Cross-origin resource sharing）跨域资源共享 CORS 详解。看名字就知道这是处理跨域问题的标准做法。CORS有两种请求，简单请求和非简单请求。

这里引用上面链接阮一峰老师的文章说明一下简单请求和非简单请求。
浏览器将CORS请求分成两类：简单请求（simple request）和非简单请求（not-so-simple request）。

只要同时满足以下两大条件，就属于简单请求。
（1) 请求方法是以下三种方法之一：

  • HEAD
  • GET
  • POST

（2）HTTP的头信息不超出以下几种字段：

  • Accept
  • Accept-Language
  • Content-Language
  • Last-Event-ID
  • Content-Type：只限于三个值application/x-www-form-urlencoded、multipart/form-data、text/plain

1.简单请求
后端

// 处理成功失败返回格式的工具
const {successBody} = require('../utli')
class CrossDomain {
  static async cors (ctx) {
    const query = ctx.request.query
    // *时cookie不会在http请求中带上
    ctx.set('Access-Control-Allow-Origin', '*')
    ctx.cookies.set('tokenId', '2')
    ctx.body = successBody({msg: query.msg}, 'success')
  }
}
module.exports = CrossDomain

前端什么也不用干，就是正常发请求就可以，如果需要带cookie的话，前后端都要设置一下，下面那个非简单请求例子会看到。

fetch(`http://localhost:9871/api/cors?msg=helloCors`).then(res => {
  console.log(res)
})

2.非简单请求
非简单请求会发出一次预检测请求，返回码是204，预检测通过才会真正发出请求，这才返回200。这里通过前端发请求的时候增加一个额外的headers来触发非简单请求。
clipboard.png

后端

// 处理成功失败返回格式的工具
const {successBody} = require('../utli')
class CrossDomain {
  static async cors (ctx) {
    const query = ctx.request.query
    // 如果需要http请求中带上cookie，需要前后端都设置credentials，且后端设置指定的origin
    ctx.set('Access-Control-Allow-Origin', 'http://localhost:9099')
    ctx.set('Access-Control-Allow-Credentials', true)
    // 非简单请求的CORS请求，会在正式通信之前，增加一次HTTP查询请求，称为"预检"请求（preflight）
    // 这种情况下除了设置origin，还需要设置Access-Control-Request-Method以及Access-Control-Request-Headers
    ctx.set('Access-Control-Request-Method', 'PUT,POST,GET,DELETE,OPTIONS')
    ctx.set('Access-Control-Allow-Headers', 'Origin, X-Requested-With, Content-Type, Accept, t')
    ctx.cookies.set('tokenId', '2')

    ctx.body = successBody({msg: query.msg}, 'success')
  }
}
module.exports = CrossDomain

一个接口就要写这么多代码，如果想所有接口都统一处理，有什么更优雅的方式呢？见下面的koa2-cors。

const path = require('path')
const Koa = require('koa')
const koaStatic = require('koa-static')
const bodyParser = require('koa-bodyparser')
const router = require('./router')
const cors = require('koa2-cors')
const app = new Koa()
const port = 9871
app.use(bodyParser())
// 处理静态资源 这里是前端build好之后的目录
app.use(koaStatic(
  path.resolve(__dirname, '../dist')
))
// 处理cors
app.use(cors({
  origin: function (ctx) {
    return 'http://localhost:9099'
  },
  credentials: true,
  allowMethods: ['GET', 'POST', 'DELETE'],
  allowHeaders: ['t', 'Content-Type']
}))
// 路由
app.use(router.routes()).use(router.allowedMethods())
// 监听端口
app.listen(9871)
console.log(`[demo] start-quick is starting at port ${port}`)

前端

fetch(`http://localhost:9871/api/cors?msg=helloCors`, {
  // 需要带上cookie
  credentials: 'include',
  // 这里添加额外的headers来触发非简单请求
  headers: {
    't': 'extra headers'
  }
}).then(res => {
  console.log(res)
})

4.代理
想一下，如果我们请求的时候还是用前端的域名，然后有个东西帮我们把这个请求转发到真正的后端域名上，不就避免跨域了吗？这时候，Nginx出场了。
Nginx配置

server{
    # 监听9099端口
    listen 9099;
    # 域名是localhost
    server_name localhost;
    #凡是localhost:9099/api这个样子的，都转发到真正的服务端地址http://localhost:9871 
    location ^~ /api {
        proxy_pass http://localhost:9871;
    }    
}

前端就不用干什么事情了，除了写接口，也没后端什么事情了

// 请求的时候直接用回前端这边的域名http://localhost:9099，这就不会跨域，然后Nginx监听到凡是localhost:9099/api这个样子的，都转发到真正的服务端地址http://localhost:9871 
fetch('http://localhost:9099/api/iframePost', {
  method: 'POST',
  headers: {
    'Accept': 'application/json',
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({
    msg: 'helloIframePost'
  })
})

Nginx转发的方式似乎很方便！但这种使用也是看场景的，如果后端接口是一个公共的API，比如一些公共服务获取天气什么的，前端调用的时候总不能让运维去配置一下Nginx，如果兼容性没问题（IE 10或者以上），CROS才是更通用的做法吧。

同源策略限制下Dom查询的正确打开方式

1.postMessage
window.postMessage() 是HTML5的一个接口，专注实现不同窗口不同页面的跨域通讯。
为了演示方便，我们将hosts改一下：127.0.0.1 crossDomain.com，现在访问域名crossDomain.com就等于访问127.0.0.1。

这里是http://localhost:9099/#/crossDomain，发消息方

<template>
  <div>
    <button @click="postMessage">给http://crossDomain.com:9099发消息</button>
    <iframe name="crossDomainIframe" src="http://crossdomain.com:9099"></iframe>
  </div>
</template>

<script>
export default {
  mounted () {
    window.addEventListener('message', (e) => {
      // 这里一定要对来源做校验
      if (e.origin === 'http://crossdomain.com:9099') {
        // 来自http://crossdomain.com:9099的结果回复
        console.log(e.data)
      }
    })
  },
  methods: {
    // 向http://crossdomain.com:9099发消息
    postMessage () {
      const iframe = window.frames['crossDomainIframe']
      iframe.postMessage('我是[http://localhost:9099], 麻烦你查一下你那边有没有id为app的Dom', 'http://crossdomain.com:9099')
    }
  }
}
</script>

这里是http://crossdomain.com:9099，接收消息方

<template>
  <div>
    我是http://crossdomain.com:9099
  </div>
</template>

<script>
export default {
  mounted () {
    window.addEventListener('message', (e) => {
      // 这里一定要对来源做校验
      if (e.origin === 'http://localhost:9099') {
        // http://localhost:9099发来的信息
        console.log(e.data)
        // e.source可以是回信的对象，其实就是http://localhost:9099窗口对象(window)的引用
        // e.origin可以作为targetOrigin
        e.source.postMessage(`我是[http://crossdomain.com:9099]，我知道了兄弟，这就是你想知道的结果：${document.getElementById('app') ? '有id为app的Dom' : '没有id为app的Dom'}`, e.origin);
      }
    })
  }
}
</script>

结果可以看到：

clipboard.png

2.document.domain
这种方式只适合主域名相同，但子域名不同的iframe跨域。
比如主域名是http://crossdomain.com:9099，子域名是http://child.crossdomain.com:9099，这种情况下给两个页面指定一下document.domain即document.domain = crossdomain.com就可以访问各自的window对象了。

3.canvas操作图片的跨域问题
这个应该是一个比较冷门的跨域问题，张大神已经写过了我就不再班门弄斧了解决canvas图片getImageData,toDataURL跨域问题

最后

huyao_road
关注
专栏目录
Axios、同源策略和跨域、JSONP
不明真相的末影人
06-01 603
Axios基本概念 Axios 是专注于网络数据请求的库。 相比于原生的 XMLHttpRequest 对象，axios 简单易用。 相比于 jQuery，axios 更加轻量化，只专注于网络数据请求。 axios的基本使用方式 发起get请求： axios.get(请求地址,{params: 参数}).then(function (res) {}); 发起post请求： axios.post(请求地址,{data: 参数}).then(function (res) {}); axios.post(请求地
同源与跨域
FantasyBreaker的博客
02-08 169
1995年，同源政策由 Netscape 公司引入浏览器。目前，所有浏览器都实行这个政策。同源策略：最初，它的含义是指，A网页设置的 Cookie，B网页不能打开，除非这两个网页"同源"。 所谓"同源"指的是"三个相同"：协议相同、域名相同、端口相同。 本域脚本只能读写本域内的资源，而无法访问其它域的资源。这种安全限制称为同源策略。 同源政策的目的，是为了保证用户信息的安全，防止恶意的网站窃取数据。 同源策略的限制： Cookie、LocalStorage 和 IndexDB 无法读取。 DOM 无法获得
跨域问题、同源策略、CORS机制、Nginx解决跨域问题（AI问答，仅供参考）
最新发布
宋冠巡的博客
09-24 1240
跨域问题、同源策略、CORS机制、Nginx解决跨域问题。 跨域问题通常是指在浏览器中由于同源策略（Same-origin policy）的限制而引起的问题。同源策略是Web安全的一个基本概念，它的目的是防止某个文档或脚本从一个来源加载资源时非法访问或修改另一个来源的资源或数据。这里的“来源”（origin）由协议（http/https）、域名（domain name）以及端口（port）三者共同确定。如果这三个条件完全相同，则认为是同源；否则，即为不同源。
前端必备HTTP技能之同源策略详解
Catie
09-09 953
同源策略在web应用的安全模型中是一个重要概念。在这个策略下，web浏览器允许第一个页面的脚本访问第二个页面里的数据，但是也只有在两个页面有相同的源时。源是由URI，主机名，端口号组合而成的。这个策略可以阻止一个页面上的恶意脚本通过页面的DOM对象获得访问另一个页面上敏感信息的权限。 对于普遍依赖于cookie维护授权用户session的现代浏览器来说，这种机制有特殊意义。客户端必须在不同站点提
同源策略和跨域解决方案——JSONP、CORS、代理跨域（vue-cli脚手架搭建代理服务器）
m0_55734628的博客
08-29 2859
在简单请求中，只要满足简单请求的要求，一般情况下，是不怎么需要服务端去进行配置的，除了Access-Control-Allow-Origin这个字段是必备的OPTIONS请求作为预检请求，就算请求方法没有在Access-Control-Allow-Methods规定范围内也不会出现错误，但是我们不能自己发送OPTIONS请求CORS跨域设置涉及到后端和前端的配合。后端通过设置响应头来允许特定的跨域请求，而前端则需要确保请求头中包含适当的信息。这样可以保障安全地进行跨域资源访问参考文档：MDN。
同源策略与跨域
热门推荐
mijichui2153的博客
11-21 1万+
前言：最近业务上前端同学多次联系说访问腾讯云cos资源的时候因为跨域的问题访问不到。大致看了下腾讯云关于设置跨域访问的教程，按照前端同学给的域名等选项就给配了，而且测试下来也是好的。但是呢一直不知道什么是跨域这里就做一个简单的学习记录。 一、同源策略 同源策略(Same Origin Policy)是一种约定，它是浏览器最核心也是最基本的安全功能。同源策略会阻止一个域的javascrip脚本和另一个域的内容进行交互，是用于隔离潜在恶意文件的关键安全机制；关于这一点我们后面会举例说明。...
同源策略与cors跨域及jsonp劫持
j1044957016的博客
05-31 898
文章目录前言一、同源策略二、Ajax技术三、CORS跨域1.简单请求2.非简单请求3.漏洞成因及修复四、jsonp劫持总结 前言 本文整理同源策略，Ajax，cors跨域及jsonp劫持 一、同源策略 同源策略（Same Origin Policy）：该策略是浏览器的一个安全基石，如果没有同源策略，那么，你打开了一个合法网站，又打开了一个恶意网站。恶意网站的脚本能够随意的操作合法网站的任何可操作资源，没有任何限制。（防止内部资源被外部页面脚本读取或篡改） 浏览器的同源策略规定： 不同域的客户端脚本在没有
同源策略以及CORS跨域资源共享
Allurewuhui的博客
03-28 1577
一；同源策略： 1.同源是一种安全机制，为了预防某些恶意行为（例如 Cookie 窃取等），浏览器限制了从同一个源加载的文档或脚本如何与来自另一个源的资源进行交互。 2.满足同源要具备三方面：协议相同、域名相同、端口相同。 3.只要以上三点有一点不满足，就会产生跨域，解决跨域常见的方法：JSONP，CORS。 二；什么是CORS： 1.CORS （Cross-Origin Resource Sharing，跨域资源共享）由一系列 HTTP 响应头组成，这些 HTTP 响应头决定浏览器是否阻止前端
最新总结 什么是同源策略，CORS 跨域资源共享解决前端跨域问题
SmileLife123的博客
09-19 156
同源策略是浏览器的一种安全策略，所谓同源是指域名，协议，端口相同。出于安全考虑，浏览器只允许与同源的服务器进行交互，否则就会产生跨域，浏览器控制台就会抛出异常。上面讲到不同源就会报错，那怎么与不同源的服务器进行交互呢？接下来CORS就要登场了。CORS 是一个W3C标准 全称为 “跨域资源共享”（Cross-origin resource sharing），它允许浏览器向跨源服务器，发出 XMLHttpRequest 请求。
什么是同源策略及解决跨域的三种方式
m0_65849649的博客
03-30 293
同源策略 1.1.1 所谓同源是指"协议+域名+端口"三者相同，即便两个不同的域名指向同一个 ip 地址，也非同源。同源策略/SOP（Same origin policy）是一种约定，由 Netscape 公司 1995 年引入浏览器，它是浏览器最核心也最基本的安全功能，现在所有支持 JavaScript 的浏览器都会使用这个策略。如果缺少了同源策略，浏览器很容易受到 XSS、 CSFR 等攻击。 {1} 比如一个web应用，用户访问的页面，处理页面的请求的controller都是在同一个context
同源和跨域
weixin_30739595的博客
03-23 61
理解什么是同源，跨域 同源：域名、协议、端口完全相同。 跨域：域名、协议、端口有其中的一样不同。 什么是同源策略 同协议、同domain（或ip）、同端口，视为同一个域，一个域内的脚本仅仅具有本域内的权限。 理解：本域脚本只能读写本域内的资源，而无法访问其它域的资源。这种安全限制称为同源策略。　　 前端解决跨域访问的常用方式 　　1.jsonp 　　2.iframe 元...
跨域和同源详解
sky89299的博客
04-05 2448
跨域 同源策略 开发过程中主要遇到的同源问题，主要是比较两个url是否同源。 判断条件 协议是否相同（http、https、file） 主机地址是否相同（www.xxx.com 127.0.0.1） 端口（0~65535）http默认的电动车需按扣是80（可以不写），https默认端口是443 ， MySQL默认的端口是3306 如果两个url协议、主机地址、端口都相同，那么这两个url是同源，否则就是非同源 非同源受到限制： Cookie无法操作 DOM无法操作 Ajax请求无效（请求
web api同源策略
asd09288917的博客
08-27 88
1.重写JsonMediaTypeFormatter public class JsonpMediaTypeFormatter : JsonMediaTypeFormatter { private string _callbackQueryParameter; public JsonpMediaTypeFormatter() { Supported...
跨域？同源？一次搞懂什么是跨域
leoyongyuan的博客
07-01 1249
其实在我们用ajax传输数据时，很多时候都是在做跨域请求，如果没租过服务器的小伙伴可能没去捣鼓过这东西是什么。跨域其实在我们前后端数据交互非常常见，但是现在的模块化时代，一般我们不怎么会接触到跨域问题，因为很多事API已经帮我们解决了。接下来我就给大家好好捋清跨域是怎么回事。在先介绍跨域之前我觉得必须先普及同源策略的概念。 什么是同源？ 如果两个页面的协议，域名和端口都相同，则两个页面具有相同的源。 例如，下表给出了相对于http://www.test com/index.html页面的同源检测: 为了防
跨域/解决跨域方法
song854601134的博客
12-19 4244
首先编写一个过滤器，可以起名字为MyCorsFilter.java} }.} }.} }.} }.} }.} }.} }.} }.} }.} }.} }.
同源和跨域以及解决方法
wutongheihei666的博客
05-10 399
一、概述 1.含义 同源策略是浏览器的一种安全策略。 最初，它的含义是指，A网页设置的 Cookie，B网页不能打开，除非这两个网页"同源"。 同源指的是三个相同 协议 域名 端口号 举例来说，http://www.example.com/dir/page.html这个网址，协议是http://，域名是www.example.com，端口是80（默认端口可以省略）。它的同源情况如下。 http://www.example.com/dir2/other.html：同源 http://example.c
理解Web安全基础：同源策略与跨域访问解析
"深入浅析同源策略和跨域访问" 同源策略是Web安全的基础，它是由浏览器实施的一种安全机制，确保来自不同源的Web内容无法相互交互，以防止恶意站点窃取或篡改数据。同源策略规定，只有当两个URL的协议（如HTTP或...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值