Web浏览器设计之初并未考虑进mashup应用，‘这个疮疤自它诞生之日就有了’[David Boloker，OpenAjax联盟创始人之一，IBM新兴网络技术(Emerging Internet Technologies)的CTO]说到。浏览器包含一种叫同源策略的安全机制，能够防止一个站点的恶意代码从另一站点上抓取诸如存储的证书之类的数据。同源策略限制了来自一个域的站点向另一个域请求数据。
来自微软研究院系统与网络组的Helen Wang进一步指出了同源策略的失败之处：
同源策略的失败在于它迫使‘现在的网络应用，要么选择牺牲掉安全，要么选择牺牲掉功能。’她提到很多很棒的功能（比如mashup）来自于使用各个来源的工具。问题是当站点的创建者在自己的站点嵌入第三方代码时，同源策略不再提供任何的保护，因此这些嵌入代码极有可能获得对存储于该站点的信息的访问权限
一些提出的解决方案包括：在辅以额外控制的同时，放宽同源策略的限制。Wang建议以“沙盒”的形式在浏览器内对外部代码加以控制，避免（这些代码）获得过多的权限。也有人推荐用外部的、第三方工具来确保应用程序通信安全，这种方式不必改动现有的浏览器。一个这样的例子是IBM最近宣布的sMash，一个“安全的mashup”应用：
sMash致力于解决浏览器mashup安全问题中的一个关键部分，使来自于异源的数据和代码相互分离，与此同时，通过一个安全的通信通道充许数据在受控状态下得以共享
业界的大多数人都试图表明mashup安全仍是一个悬而未决的问题，随着Web2.0应用的普及，这一问题将会得到越来越多的关注。尽管mashup并不是应用的全部，但BEA一直以来都把重点放在为组织创建服务的开发者身上。Bob Rhubart在一家公司讨论“作为SOA项目整体一部分的安全性”时提到，安全是任何SOA全局治理的基石：
要说明安全之于SOA治理的重要性，将它比作水之于鱼的生存也不为过。这是显而易见的。就像SOA治理中的其他环节一样，安全问题也是一个多方面的问题。但它的本质归根结底在于回答一个简单的问题：谁在使用你的东西？部署于SOA中的每一个服务都代表着一笔重大的投资，同时也代表着潜在的重大回报。当然了，SOA治理的一个根本目的，就是保证每个服务的使用都能产生所预期的回报。实现这个回报的关键，一是控制好谁能访问这些服务，二是控制好那些有权使用的人到底是怎样使用服务的。
Rhubart援引了David Garrison和BEA的安全服务框架作为如何实现这一目标的例子。Garrison指出，BEA在他们的产品中使用了一个安全服务框架模型，并讨论了如何用AquaLogic企业安全套件(ALES)来设计这样一种框架的基本理念。Garrison为一个安全服务框架标定出了5个主要的服务/提供者，并阐述了它们各自的职责。它们是：
- 认证
- 角色映射
- 授权
- 证书映射
- 审计
不出意料，所列的项目与传统的应用级安全框架相异甚少。
