當應用程式滿足以下條件時，會發生跨框架指令碼弱點：

1. 允許在 iframe 內納入自身。
2. 無法透過 X-Frame-Options 表頭指定框架原則。
3. 使用欠佳的保護措施，例如，以 JavaScript 為基礎的框架突破邏輯。

跨框架指令碼弱點通常是點擊劫持攻擊的基礎，攻擊者可能使用此攻擊來發起跨網站偽造要求或網路釣魚攻擊。

HTML5 提供 localStorage 和 sessionStorage 對應，可讓開發人員維持程式值。sessionStorage 對應提供呼叫頁面的儲存空間，且持續時間為頁面實例和即時瀏覽器階段作業運算期間。但 localStorage 對應則是提供可在多個頁面實例和瀏覽器實例存取的儲存空間。此功能可讓應用程式在多個瀏覽器標籤或視窗中維持並使用相同的資訊。

舉例來說，開發人員想要在旅遊應用程式中使用多個瀏覽器標籤或實例，讓使用者可以開啟多個標籤來比較住宿方案，同時也可以保持使用者原本的搜尋條件。在傳統的 HTTP 儲存方法中，使用者進行購物時存在一定風險，且在某個標籤中所做的決定 (已儲存在階段作業或 Cookie 中) 會干擾另一個標籤中的購物操作。

使用可在多個瀏覽器標籤中利用使用者數值的功能時，開發人員必須特別謹慎，別將敏感資訊從 sessionStorage 範圍移至 localStorage (反之亦然)。

範例 1：以下範例將信用卡 CCV 資訊儲存在工作階段中，表示使用者已授權網站對已建檔的信用卡收取購物費用。每次要在此瀏覽器索引標籤頁面中購物時，都必須核准信用卡。為了避免再次輸入 CCV，該資訊會儲存在 sessionStorage 物件中。但是，開發人員也會將資訊儲存在 localStorage 物件中。

...
try {
    sessionStorage.setItem("userCCV", currentCCV);
} catch (e) {
    if (e == QUOTA_EXCEEDED_ERR) {
        alert('Quota exceeded.');
    }
}

...
...

var retrieveObject = sessionStorage.getItem("userCCV");
try {
    localStorage.setItem("userCCV",retrieveObject);
} catch (e) {
    if (e == QUOTA_EXCEEDED_ERR) {
        alert('Quota exceeded.');
    }
    ...

    var userCCV = localStorage.getItem("userCCV");
    ...
}
...

藉由將資訊放回 localStorage 物件中，使用者可以在其他瀏覽器標籤中和呼叫新瀏覽器時使用 CCV 資訊。這樣會略過應用程式原本工作流程的邏輯。

Cross-Site Request Forgery (CSRF) 弱點會在以下情況中出現：
1.Web 應用程式使用了階段作業 Cookie。
2.應用程式在回應 HTTP 要求時，沒有驗證該要求是否經使用者同意產生。

範例 1：在下列範例中，Web 應用程式允許管理員建立新帳戶：

  RequestBuilder rb = new RequestBuilder(RequestBuilder.POST, "/new_user");
  body = addToPost(body, new_username);
  body = addToPost(body, new_passwd);
  rb.sendRequest(body, new NewAccountCallback(callback));

攻擊者可能會設定一個包含下列程式碼的惡意網站：

  RequestBuilder rb = new RequestBuilder(RequestBuilder.POST, "http://www.example.com/new_user");
  body = addToPost(body, "attacker";
  body = addToPost(body, "haha");
  rb.sendRequest(body, new NewAccountCallback(callback));

如果 example.com 管理員在網站上具有作用中階段作業時造訪了惡意頁面，則會在不知情的情況下為攻擊者建立帳戶。這就是 CSRF 攻擊。這樣是有可能的，因為應用程式無法確定要求的來源。因此任何要求可能是使用者選擇的合法操作，也可能是由攻擊者建立的偽造操作。攻擊者不會看到假造的要求所產生的網頁，所以這種攻擊技術只有對修改應用程式狀態的要求有用。

在 URL 中傳遞階段作業識別碼而非當作 Cookie 的應用程式不會有 CSRF 問題，因為攻擊者沒有辦法存取階段作業識別碼並將其作為假造要求的一部分。

有些架構會自動包含 CSRF nonce 以協助保護應用程式。停用此功能可能使應用程式處於風險之中。

範例 2：這個受 Spring Security 保護的應用程式明確停用了 CSRF 保護。

	<http auto-config="true">
        ...
        <csrf disabled="true"/>
	</http>

當網站必須能夠為使用者提供下載時，開啟這些下載的選項意味著在瀏覽器中執行的任何已提供檔案都可以在與該網站相同的安全環境中，於目前瀏覽器中開啟。
如果攻擊者能夠操縱下載的檔案，便可插入在瀏覽器中執行的 HTML 或指令碼來充當 Cross-site scripting 攻擊，從而竊取或操縱目前階段作業中的資訊。

範例 1：以下範例明確停用了針對在瀏覽器中執行的已提供下載的防護。

var express = require('express');
var app = express();
var helmet = require('helmet');

app.use(helmet({
    ieNoOpen: false
}));
...

當使用者受騙而造訪了惡意網站，該惡意網站將會與合法後端伺服器建立 WebSocket 連線時，Cross-Site WebSocket Hijacking 便會發生。用於要求伺服器升級至 WebSocket 通訊協定的初始 HTTP 要求是一般的 HTTP 要求，因此瀏覽器將會傳送任何繫結至目標網域的 Cookie (包括任何階段作業 Cookie)。如果伺服器無法驗證 Origin 表頭，將會允許任何惡意網站模擬使用者，並在使用者甚至無法注意到的情況下，建立雙向 WebSocket 連線。

應用程式使用 exclude 拒絕清單。這難以維護且容易出錯。如果開發人員向表單或備份表單的 Model 新增欄位，但卻忘記更新 exclude 篩選，則可能會將敏感欄位暴露給攻擊者。攻擊者將能夠提交惡意資料並將其繫結至任何非排斥性欄位。

範例 1：以下表單暴露某些 User 屬性，但會針對使用者 id 檢查拒絕清單：

from myapp.models import User
...
class UserForm(ModelForm):
  class Meta:
    model = User
    exclude = ['id']
...

如果已使用新的 role 屬性來更新 User 模型，但關聯的 UserForm 並未更新，則會在表單中暴露 role 屬性。

當滿足以下條件時，會發生 File Based Cross Zone Scripting：

1. 載入會讓 Script 在應用程式內執行的檔案。

2. 載入的 Script 是視為執行中應用程式的相同來源。

若這兩個條件均符合，即會導致一系列攻擊，特別是如果其他方根據資訊是否來自應用程式內部來判定是否可信賴。

範例 1：以下程式碼使用 Android WebView 以便在本地載入檔案：

...
myWebView.loadUrl("file:///android_asset/www/index.html");
...

在 Example 1 中，Android WebView 轉譯器會將所有透過 loadUrl() (具有開頭為「file://」的 URL) 載入的程式碼視為位於同一來源。

在從檔案載入時，攻擊者透過以下幾種典型方式來利用 File Based Cross-Zone Scripting 弱點：
- 本地檔案由其他攻擊者所控制，該攻擊者會將 Script 插入檔案。
這取決於檔案權限、檔案位置或檔案可能的儲存位置及載入位置的競賽條件 (會有一個用於執行修改的時間窗口)。

- 檔案可能會召喚外部資源。
當載入的檔案從外部資源擷取 Script 時，可能會發生此情況。

範例 2：以下程式碼會查看外部來源以確定應該執行的 JavaScript。

  <script src="http://www.example.com/js/fancyWidget.js"></script>

在 Example 2 中，使用不安全的通訊協定會讓惡意動作執行者修改產生的指令碼。或者，可能會執行其他攻擊以將機器重新路由到攻擊者的站台。

- 載入的檔案可能包含 Cross-site scripting 弱點。
如果載入的檔案可插入程式碼，則插入的程式碼可在應用程式內容中執行。沒有必要非要插入 JavaScript，只需插入 HTML 亦可允許塗改或 Denial of Service 攻擊。

依預設，Flash 應用程式需遵守相同來源策略 (Same Origin Policy)，它可以確保只有在兩個 SWF 應用程式都來自相同網域時，才可以存取彼此的資料。Adobe Flash 允許開發人員在程式上或透過 crossdomain.xml 組態設定檔案的適當設定來修改策略。但是，變更設定時應特別小心，因為過度允許的跨網域策略會允許惡意應用程式以不適當的方式與受害者應用程式通訊，導致欺騙、資料遭竊取、傳遞和其他攻擊。

範例 1：以下內容是使用萬用字元在程式上指定允許應用程式與哪些網域通訊的範例。

   flash.system.Security.allowDomain("*");

使用 * 做為給 allowDomain() 的引數，表示應用程式的資料可以讓其他來自任何網域的 SWF 應用程式存取。

依預設，Flash 應用程式需遵守相同來源策略 (Same Origin Policy)，它可以確保只有在兩個 SWF 應用程式都來自相同網域時，才可以存取彼此的資料。Adobe Flash 允許開發人員在程式上或透過 crossdomain.xml 組態設定檔案的適當設定來修改策略。從 Flash Player 9,0,124,0 開始，Adobe 也引進了定義 Flash Player 可以在網域間傳送哪些自訂表頭的功能。但是，定義這些設定時應特別小心，因為將過度允許的自訂表頭策略和過度允許的跨網域策略一起套用時，會允許惡意應用程式將其選擇的表頭傳送到目標應用程式，可能會導致多種攻擊，或在不知道如何處理所接收之表頭的應用程式執行中造成錯誤。

範例 1：以下配置顯示了使用萬用字元指定 Flash Player 可以在網域間傳送哪些標頭。

  <cross-domain-policy>
    <allow-http-request-headers-from domain="*" headers="*"/>
  </cross-domain-policy>

使用 * 做為 headers 屬性的值，表示任何表頭都會在網域間傳送。

依預設，Flash 應用程式需遵守相同來源策略 (Same Origin Policy)，它可以確保只有在兩個 SWF 應用程式都來自相同網域時，才可以存取彼此的資料。Adobe Flash 允許開發人員在程式上或透過 crossdomain.xml 組態設定檔案的適當設定來修改策略。但是，決定誰可以影響設定時應特別小心，因為過度允許的跨網域策略會允許惡意應用程式以不適當的方式與受害者應用程式通訊，導致欺騙、資料遭竊取、傳遞和其他攻擊。Policy restrictions bypass 弱點會在以下情況中出現：

1. 資料從不可信賴的來源進入應用程式。

2. 資料用來載入或修改跨網域策略設定。
範例 1：以下程式碼對載入的 SWF 檔案使用其中一個參數的值，做為載入跨網域策略檔案的來源 URL。

   ...
   var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
   var url:String = String(params["url"]);
   flash.system.Security.loadPolicyFile(url);
   ...

範例 2：以下程式碼對載入的 SWF 檔案使用其中一個參數的值，以定義可信任網域的清單。

   ...
   var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
   var domain:String = String(params["domain"]);
   flash.system.Security.allowDomain(domain);
   ...

從 Flash Player 7 開始，透過 HTTP 載入的 SWF 應用程式不允許存取預設透過 HTTPS 載入的 SWF 應用程式。Adobe Flash 允許開發人員在程式上或透過 crossdomain.xml 組態設定檔案的適當設定來修改此限制。但是，定義這些設定時應特別小心，因為 HTTP 載入的 SWF 應用程式容易遭到 man-in-the-middle 攻擊，因此不應該受信賴。

範例 1：以下程式碼會呼叫 allowInsecureDomain()，它會關閉以下限制：防止 HTTP 載入的 SWF 應用程式存取 HTTPS 載入之 SWF 應用程式的資料。

   flash.system.Security.allowInsecureDomain("*");

開發作業一般會為了除錯或測試目而增加一些「後門」程式碼，這些程式碼不會隨應用程式一起提供或部署。當這類除錯程式碼意外地留在應用程式中時，會導致應用程式開放在未預期的互動模式。這些後門入口點很容易造成安全問題，因為在設計或者測試期間，並沒有將它們考慮在內，並且不會出現在應用程式設計中的操作環境中。

GraphiQL 是一種瀏覽器內工具，它利用 GraphQL 結構描述自我檢查機制為 GraphQL API 開發和測試提供圖形介面。GraphiQL 可協助使用者探索 GraphQL 結構描述以及撰寫和執行 GraphQL 查詢。

不建議允許存取生產階段中的 GraphiQL，因為透過 GraphiQL 啟用 GraphQL 結構描述的自我檢查，可能會使您的整體安全態勢面臨風險。攻擊者可能使用 GraphiQL 和自我檢查從 GraphQL 結構描述中取得實作詳情，進而使他們能夠執行更具目標性的攻擊。GraphQL 結構描述可能會洩漏資訊，例如內部使用的欄位、描述和過時說明，這些資訊可能非供公開使用。

範例 1：以下程式碼將初始化一個預設啟用 GraphiQL 的 GraphQL.js 端點：

app.use('/graphql', graphqlHTTP({
    schema
}));

GraphQL 自我檢查功能讓任何人都可以查詢 GraphQL 伺服器以取得目前結構描述的相關資訊。當事人可以發出 GraphQL 自我檢查查詢來擷取結構描述的可用操作、資料類型、欄位和文件的完整檢視。

GraphQL 自我檢查在開發和共用有關 GraphQL API 的資訊的環境中提供重要的公用程式。自我檢查是一個強大的 GraphQL 功能，可以促進與各種工具的整合。例如，IDE 可以利用結構描述自我檢查來提供用於開發和測試 GraphQL API 的增強功能。

但是，允許任何人在生產階段中查詢您的 GraphQL 結構描述，可能會使您的整體安全態勢面臨風險。攻擊者可能使用自我檢查從 GraphQL 結構描述中取得實作詳情，進而使他們能夠執行更具目標性的攻擊。GraphQL 結構描述可能會洩漏資訊，例如內部使用的欄位、描述和過時說明，這些資訊可能非供公開使用。

範例 1：以下程式碼將初始化一個預設啟用結構描述自我檢查的 Hot Chocolate GraphQL 端點：

    services
        .AddGraphQLServer()
        .AddQueryType<Query>()
        .AddMutationType<Mutation>();
    

包含另外一個網站中可執行的內容是有風險的。這樣會導致您網站的安全性與另一個網站息息相關。

範例 1：請考慮以下 script 標籤。

  <script src="http://www.example.com/js/fancyWidget.js"></script>

如果這個標籤出現在 www.example.com 以外的網站上，則該網站依賴 www.example.com 提供正確且無惡意的程式碼。如果攻擊者能危害 www.example.com，他們就能修改 fancyWidget.js 的內容來破壞網站的安全性。例如，他們可以新增程式碼至 fancyWidget.js 來竊取使用者的機密資料。

程式設計師通常會信任隱藏欄位的內容，預期使用者無法檢視或竄改他們的內容。攻擊者將會推翻這些假設。他們會檢查寫入隱藏欄位的值並加以修改，或以攻擊資料取代這些內容。

範例 1：

  Hidden hidden = new Hidden(element);

若隱藏欄位具有敏感資訊，該資訊的快取方式將與其他的頁面相同。這可能會導致敏感資訊在使用者不知情的狀況下貯存至瀏覽器快取中。

HTML5 的功能之一便是在用戶端 SQL 資料庫儲存資料的能力。開始從資料庫寫入和讀取時，最重要的資訊就是其名稱。因此，各使用者的資料庫名稱必須為唯一字串。如果資料庫名稱很容易猜中，那麼未授權的對象 (如其他使用者) 便可能偷取敏感資料或毀損資料庫項目。
範例 1：下列程式碼使用了易於猜中的資料庫名稱：

...
var db = openDatabase('mydb', '1.0', 'Test DB', 2 * 1024 * 1024);
...

此程式碼將成功執行，但能夠猜到資料庫名稱為 'mydb' 的人都可以加以存取。

內容安全性原則 (CSP) 是一種宣告式安全性標頭，可讓開發人員指示在網頁瀏覽器中轉譯時，允許網站從哪些網域載入內容或起始到哪些網域的連線。除了程式碼中的輸入驗證和檢查允許清單外，它還提供額外一層的安全性，以防禦重要弱點，例如，Cross-Site Scripting、Clickjacking、Cross-Origin Access 等。但設定不當的標頭無法提供這種額外一層的安全性。該原則藉助於 15 個指令進行定義，其中包括 8 個用於控制資源存取的指令，即：script-src、img-src、object-src、style_src、font-src、media-src、frame-src、connect-src。

每個指令都使用來源清單做為一個值，此值指定針對該指令所涵蓋的功能，網站可存取的網域。開發人員可使用萬用字元 * 來指示所有或部分來源。所有指令都不是強制性的。瀏覽器將允許未列示指令的所有來源，或從選用的 default-src 指令衍生值。此外，此表頭的規格隨著時間的推移而不斷演變。在第 23 版之前的 Firefox 和第 10 版之前的 IE 中，其實做為 X-Content-Security-Policy，而在第 25 版之前的 Chrome 中，其實做為 X-Webkit-CSP。兩個名稱都已棄用，取代為現在的標準名稱 Content Security Policy。鑒於指令的數目、兩個棄用的替代名稱，以及對待多次出現之同一表頭和單一表頭中重複指令的方式，開發人員很可能會錯誤地配置此表頭。

考慮以下配置錯誤的情況：

- 具有 unsafe-inline 或 unsafe-eval 的指令違背了 CSP 的目的。
- 已設定 script-src 指令，但未配置任何 Script nonce。
- 已設定 frame-src，但未配置任何 sandbox。
- 在同一回應中允許使用此表頭的多個實例。開發團隊和安全性團隊可能都會設定表頭，但其中一個可能會使用棄用的名稱之一。雖然在不存在具有最新名稱 (即，內容安全性原則) 的表頭時會接受棄用的表頭，但如果存在具有 content-security-header 名稱的原則，便會忽略棄用的表頭。舊版本只理解棄用的名稱，因此，要實現預期支援，回應必須包含具有這三個名稱的相同原則。
- 如果在表頭的同一實例中重複出現某個指令，則會忽略之後出現的所有該指令。

範例 1：以下 django-csp 配置使用不安全的指令 unsafe-inline 和 unsafe-eval，以便允許內嵌 Script 和程式碼評估：

...
MIDDLEWARE = (
    ...
    'csp.middleware.CSPMiddleware',
    ...
)
...
CSP_DEFAULT_SRC = ("'self'", "'unsafe-inline'", "'unsafe-eval'", 'cdn.example.net')
...

內容安全性原則 (CSP) 是一種宣告式安全性標頭，可讓開發人員指示在網頁瀏覽器中轉譯時，允許網站從哪些網域載入內容或起始到哪些網域的連線。除了程式碼中的輸入驗證和檢查允許清單外，它還提供額外一層的安全性，以防禦重要弱點，例如，Cross-Site Scripting、Clickjacking、Cross-Origin Access 等。

依預設，Spring Security 和其他架構並不新增內容安全性原則標頭。Web 應用程式作者必須宣告一或多個安全性原則，以強制執行或監視受保護的資源，進而從這額外一層的安全性受益。

允許將您的網站新增到框架會引起安全問題。例如，這可能導致點擊劫持弱點，或允許不希望的跨框架通訊。

依預設，Spring Security 之類的架構包含 X-Frame-Options 標頭，以指示瀏覽器是否應對應用程式進行框架處理。停用或未設定此標頭會導致跨框架相關弱點。

範例 1：以下程式碼會將受 Spring Security 保護的應用程式設定為停用 X-Frame-Options 標頭：

	<http auto-config="true">
        ...
        <headers>
            ...
            <frame-options disabled="true"/>
        </headers>
	</http>