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個主要的服務/提供者，并闡述了它們各自的職責。它們是：
- 認證
- 角色映射
- 授權
- 證書映射
- 審計
不出意料，所列的項目與傳統的應用級安全框架相異甚少。
