封裝是要劃定清楚的界限。在網頁瀏覽器中，這可能意味著確保您的行動程式碼不會被其他行動程式碼濫用。在伺服器上，這可能意味著區分經過驗證的資料與未經驗證的資料、區分一個使用者的資料與另一個使用者的資料，或區分允許使用者查看的資料與不允許查看的資料。
localStorage 與 sessionStorage 之間傳遞數值時，可能在不知不覺中暴露敏感資訊。localStorage 和 sessionStorage 對應，可讓開發人員維持程式值。sessionStorage 對應提供呼叫頁面的儲存空間，且持續時間為頁面實例和即時瀏覽器階段作業運算期間。但 localStorage 對應則是提供可在多個頁面實例和瀏覽器實例存取的儲存空間。此功能可讓應用程式在多個瀏覽器標籤或視窗中維持並使用相同的資訊。sessionStorage 範圍移至 localStorage (反之亦然)。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 資訊。這樣會略過應用程式原本工作流程的邏輯。MyAccountActions 和頁面動作方法 pageAction()。pageAction() 方法會在造訪頁面 URL 時執行，而伺服器不會檢查防 CSRF 權杖。
<apex:page controller="MyAccountActions" action="{!pageAction}">
...
</apex:page>
public class MyAccountActions {
...
public void pageAction() {
Map<String,String> reqParams = ApexPages.currentPage().getParameters();
if (params.containsKey('id')) {
Id id = reqParams.get('id');
Account acct = [SELECT Id,Name FROM Account WHERE Id = :id];
delete acct;
}
}
...
}
<img src="http://my-org.my.salesforce.com/apex/mypage?id=YellowSubmarine" height=1 width=1/>
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 攻擊。這樣是有可能的，因為應用程式無法確定要求的來源。因此任何要求可能是使用者選擇的合法操作，也可能是由攻擊者建立的偽造操作。攻擊者不會看到假造的要求所產生的網頁，所以這種攻擊技術只有對修改應用程式狀態的要求有用。
<http auto-config="true">
...
<csrf disabled="true"/>
</http>
var req = new XMLHttpRequest();
req.open("POST", "/new_user", true);
body = addToPost(body, new_username);
body = addToPost(body, new_passwd);
req.send(body);
var req = new XMLHttpRequest();
req.open("POST", "http://www.example.com/new_user", true);
body = addToPost(body, "attacker");
body = addToPost(body, "haha");
req.send(body);
example.com 管理員在網站上的有效階段作業期間造訪惡意頁面，則會在不知不覺中為攻擊者建立帳戶。這就是 CSRF 攻擊。這樣是有可能的，因為應用程式無法確定要求的來源。因此不論是使用者建立的或是由攻擊者建立的偽造操作，都會被視為合法的操作。攻擊者不會看到假造的要求所產生的網頁，所以這種攻擊技術只有對修改應用程式狀態的要求有用。
<form method="POST" action="/new_user" >
Name of new user: <input type="text" name="username">
Password for new user: <input type="password" name="user_passwd">
<input type="submit" name="action" value="Create User">
</form>
<form method="POST" action="http://www.example.com/new_user">
<input type="hidden" name="username" value="hacker">
<input type="hidden" name="user_passwd" value="hacked">
</form>
<script>
document.usr_form.submit();
</script>
example.com 管理員在網站上的有效階段作業期間造訪惡意頁面，則會在不知不覺中為攻擊者建立帳戶。這就是 CSRF 攻擊。這樣是有可能的，因為應用程式無法確定要求的來源。因此不論是使用者建立的或是由攻擊者建立的偽造操作，都會被視為合法的操作。攻擊者不會看到假造的要求所產生的網頁，所以這種攻擊技術只有對修改應用程式狀態的要求有用。buyItem 控制項方法的 CSRF 保護。
+ nocsrf
POST /buyItem controllers.ShopController.buyItem
shop.com 的階段作業處於作用中狀態期間受騙而造訪惡意頁面，則該使用者會不知不覺地為攻擊者購買項目。 這就是 CSRF 攻擊。 這樣是有可能的，因為應用程式無法確定要求的來源。 因此任何要求可能是使用者選擇的合法操作，也可能是由攻擊者建立的偽造操作。 攻擊者不會看到假造的要求所產生的網頁，所以這種攻擊技術只有對修改應用程式狀態的要求有用。
<form method="POST" action="/new_user" >
Name of new user: <input type="text" name="username">
Password for new user: <input type="password" name="user_passwd">
<input type="submit" name="action" value="Create User">
</form>
<form method="POST" action="http://www.example.com/new_user">
<input type="hidden" name="username" value="hacker">
<input type="hidden" name="user_passwd" value="hacked">
</form>
<script>
document.usr_form.submit();
</script>
example.com 管理員在網站上的有效階段作業期間造訪惡意頁面，則會在不知不覺中為攻擊者建立帳戶。這就是 CSRF 攻擊。這樣是有可能的，因為應用程式無法確定要求的來源。因此不論是使用者建立的或是由攻擊者建立的偽造操作，都會被視為合法的操作。攻擊者不會看到假造的要求所產生的網頁，所以這種攻擊技術只有對修改應用程式狀態的要求有用。noopen 的 X-Download-Options 標頭，允許下載的 HTML 頁面在網站向其提供的安全環境中執行。
var express = require('express');
var app = express();
var helmet = require('helmet');
app.use(helmet({
ieNoOpen: false
}));
...
Origin 表頭，將會允許任何惡意網站模擬使用者，並在使用者甚至無法注意到的情況下，建立雙向 WebSocket 連線。Origin 表頭，將會允許任何惡意網站模擬使用者，並在使用者甚至無法注意到的情況下，建立雙向 WebSocket 連線。exclude 拒絕清單。這難以維護且容易出錯。如果開發人員向表單或備份表單的 Model 新增欄位，但卻忘記更新 exclude 篩選，則可能會將敏感欄位暴露給攻擊者。攻擊者將能夠提交惡意資料並將其繫結至任何非排斥性欄位。User 屬性，但會針對使用者 id 檢查拒絕清單：
from myapp.models import User
...
class UserForm(ModelForm):
class Meta:
model = User
exclude = ['id']
...
role 屬性來更新 User 模型，但關聯的 UserForm 並未更新，則會在表單中暴露 role 屬性。
...
myWebView.loadUrl("file:///android_asset/www/index.html");
...
Example 1 中，Android WebView 轉譯器會將所有透過 loadUrl() (具有開頭為「file://」的 URL) 載入的程式碼視為位於同一來源。
<script src="http://www.example.com/js/fancyWidget.js"></script>
Example 2 中，使用不安全的通訊協定會讓惡意動作執行者修改產生的指令碼。或者，可能會執行其他攻擊以將機器重新路由到攻擊者的站台。file://) 相同的來源。UIWebView.loadRequest(_:) 方法載入本機檔案：
...
NSURL *url = [[NSBundle mainBundle] URLForResource: filename withExtension:extension];
[webView loadRequest:[[NSURLRequest alloc] initWithURL:url]];
...
Example 1 中，WebView 引擎會將所有透過 UIWebView.loadRequest(_:) (具有開頭為 file:// 的 URL) 載入的程式碼視為位於有權限的本機檔案來源。file:// URL 從本機載入，則相同來源策略 (Same Origin Policy) 將允許此檔案中的 Script 存取相同來源的任何其他檔案，這會讓攻擊者存取包含敏感資訊的任何本機檔案。file://) 相同的來源。UIWebView.loadRequest(_:) 方法載入本機檔案：
...
let url = Bundle.main.url(forResource: filename, withExtension: extension)
self.webView!.load(URLRequest(url:url!))
...
Example 1 中，WebView 引擎會將所有透過 UIWebView.loadRequest(_:) (具有開頭為 file:// 的 URL) 載入的程式碼視為位於有權限的本機檔案來源。file:// URL 從本機載入，則相同來源策略 (Same Origin Policy) 將允許此檔案中的 Script 存取相同來源的任何其他檔案，這會讓攻擊者存取包含敏感資訊的任何本機檔案。crossdomain.xml 組態設定檔案的適當設定來修改策略。但是，變更設定時應特別小心，因為過度允許的跨網域策略會允許惡意應用程式以不適當的方式與受害者應用程式通訊，導致欺騙、資料遭竊取、傳遞和其他攻擊。
flash.system.Security.allowDomain("*");
* 做為給 allowDomain() 的引數，表示應用程式的資料可以讓其他來自任何網域的 SWF 應用程式存取。