Web 應用程式安全指南/XML、JSON 和通用 API 安全
API 可能帶來額外的安全挑戰。同時，不能忽視基本的安全規則（如輸出轉義）。
為了防止這種型別的攻擊
- 確保對 API 進行適當的訪問控制
- 不要忘記你需要正確轉義所有輸出以防止 XSS 攻擊，像 XML 這樣的資料格式需要特別考慮，並且在許多情況下需要針對跨站請求偽造 (CSRF)的保護。
- 使用具有經過驗證的庫的標準資料格式，例如 JSON，並正確使用它們。這可能會滿足您所有轉義需求。
- 確保瀏覽器不會錯誤地解釋您的文件或允許跨站點載入
- 確保您的文件格式正確
- 傳送正確的 Content-Type
- 使用
X-Content-Type-Options: nosniff標頭 - 對於 XML，提供字元集並確保攻擊者無法插入任意標籤
- 對於 JSON，確保頂級資料結構是物件，並且所有在 HTML 中具有特殊意義的字元都已轉義
基本原理
某些操作通常僅限於具有適當許可權的使用者。但是，一些開發人員忘記適當地限制他們的 API，從而允許沒有適當許可權的使用者執行這些操作。確保 API 適當地執行訪問控制。請記住，您仍然需要 CSRF 保護！一個單獨的客戶端可以輕鬆地獲取令牌（但需要使用者的憑據才能這樣做），而惡意 JavaScript 卻不能（由於同源策略）。
即使您的應用程式未顯示 API 輸出，攻擊者也可以透過直接連結到它來利用它進行 XSS 攻擊。為此，您必須遵循適當的轉義規則 *並* 阻止瀏覽器錯誤地解釋您的輸出。
如果您使用標準資料格式，例如 JSON，您可以使用經過許多專業人員徹底檢查的標準庫。這將使您更容易正確地轉義內容，並節省您大量時間（和潛在的安全問題）。
某些瀏覽器喜歡將任何看起來像是 HTML 的內容都解釋為 HTML。對於 XML 文件（它也可能表示其他帶指令碼的格式，如 SVG）尤其如此。傳送格式正確的文件並設定正確的 Content-Type 使瀏覽器猜測的可能性降低。X-Content-Type-Options: nosniff 標頭將阻止瀏覽器嘗試猜測 Content-Type（最重要的是，它將停用 Internet Explorer 中的積極猜測）。
在 XML 中提供正確的字元集非常重要，因為不同的字元集會導致對資料的完全不同的解釋。例如，在 UTF-8 或其他常見字元集中無害的文字可以在 UTF-7 中變成指令碼標籤。
JSON 使用 JavaScript 語法，可能使用 <script> 標籤跨域邊界載入。結合對 Array 原型的創造性修改，這可以在過時的瀏覽器中訪問資料（繞過同源策略）。傳遞物件而不是陣列可以防止這種情況（截至 2013 年）。
建議對 JSON 中的特殊字元進行轉義，以避免內容嗅探。在 PHP 中，可以透過將 JSON_HEX_TAG 標誌傳遞給 json_encode 來實現這一點。