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

範例：

  Hidden hidden = new Hidden(element);

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

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

...
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_CLASSES = (
    ...
    '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>

內容安全性原則 (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。這 8 個指令都將一個來源清單做為值，指定網站可存取的網域，以使用該指令所涵蓋的功能。開發人員可使用萬用字元 * 來指示所有或部分來源。其他來源清單關鍵字 (例如 'unsafe-inline' 和 'unsafe-eval') 提供更精細的方式來控制 script 執行，但這些是潛在有害的關鍵字。所有指令都不是強制性的。瀏覽器允許未列示指令的所有來源，或從選用的 default-src 指令衍生值。此外，此標頭的規格隨著時間的推移而不斷演變。在第 23 版之前的 Firefox 和第 10 版之前的 IE 中，其實作為 X-Content-Security-Policy，而在第 25 版之前的 Chrome 中，則實作為 X-Webkit-CSP。兩個名稱都已棄用，取代為現在的標準名稱 Content Security Policy。鑒於指令的數目、兩個棄用的替代名稱，以及對待多次出現之同一標頭和單一標頭中重複指令的方式，開發人員很可能會錯誤地設定此標頭。

範例 1：以下程式碼會設定過度寬鬆且不安全的 default-src 指令：

	<http auto-config="true">
        ...
        <headers>
            ...
            <content-security-policy policy-directives="default-src '*'" />
        </headers>
    </http>

在 HTML5 之前，網頁瀏覽器會強制執行相同來源原則，確保在使用 JavaScript 存取網頁內容時，JavaScript 和網頁來自相同的網域。若不使用相同來源策略 (Same Origin Policy)，惡意的網站可使用用戶端的憑證來執行 JavaScript，從其他網站載入敏感的資訊，從中挑選出資訊並將資訊回傳給攻擊者。HTML5 使 JavaScript 可以在定義稱為 Access-Control-Allow-Origin 的新 HTTP 標頭時，存取不同網域間的資料。Web 伺服器可使用此標頭，定義允許使用跨來源要求存取其網域的其他網域。但是，定義標頭時請謹慎小心，因為過度許可的 CORS 原則會允許惡意應用程式以不當方式與受害應用程式通訊，進行導致詐騙、資料竊取、轉送和其他攻擊。

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

<websocket:handlers allowed-origins="*">
        <websocket:mapping path="/myHandler" handler="myHandler" />
</websocket:handlers>

使用 * 做為 Access-Control-Allow-Origin 表頭的值，表示應用程式的資料可以讓在任何網域上執行的 JavaScript 存取。