我開發，現在正在恢復與編碼的HTML實體用戶生成的內容是通過骨幹網絡應用程序所消耗（並且還通過iOS和Android應用程序）的API，所以如API客戶端將得到<div>，而不是<div> 。是否有關於返回原始HTML或不在RESTFul JSON API中的社區標準或良好規範？
這個web應用程序有任何問題，問題是iOS和Android顯示<div>，因爲它是最終的應用程序用戶。
該API即將發佈爲第三方應用程序，因此如果API返回原始HTML，任何用戶都可能注入一些惡意腳本來竊取其他用戶的信息，以防第三方應用程序沒有一種防止它的方法。
考慮到這一潛在的安全風險，這將是一個寧靜的JSON API一個很好的做法，回到原始或返回HTML編碼？
我已經看到了Twitter的API返回原始的HTML，所以我對這個混合的感覺，我不知道是否有一些共同的標準/好做法，該社區現在以下。
感謝
我相信，在一般最安全的做法是，以確保內容爲「安全」時，它是由用戶創建，而不是當你做的東西吧。
我不知道你是否有過存儲UGC的過程控制，但如果你有，在這一點上它清理乾淨。如果你不這樣做，你當然可以在API級別清理它，但是使用相同UCG輸入的任何其他內容也必須執行清理（這就是爲什麼我相信它應該在數據存儲時完成.. 。）
XSS和其他攻擊媒介進化的時候，他們都是關於「最好的辦法」等諸多問題。意見各不相同，但最簡單的可能是使用白名單的方法，明確允許某些標籤，並使用正則表達式或任何您喜歡處理此類解析類型的庫來過濾其他所有內容。 （它的編程語言你正在使用所以這是一個有點難以提供的例子你沒有提到...）
我覺得你最好的來源的信息OWASP，只是閱讀和理解攻擊是怎麼發生的，所以你也可以瞭解如何建立你的安全阻止他們。最重要的是，不斷更新主題，安全性不是一次性的努力，它應該是貫穿您所有開發過程的連續過程。
也看到，爲什麼編碼是不是真的很好的解決這個特定條目（如您懷疑） https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet#Why_Can.27t_I_Just_HTML_Entity_Encode_Untrusted_Data.3F
我也並不認爲這是一個「最佳實踐」，總有一些因素，你不能控制，並且需要變得「具有創造性」，並且仍然保證您以不同方式控制的軟件塊，即使這不是「標準」。
另一個好的做法是在您的開發/測試周期中將這種類型的漏洞測試包含到知道您的API是安全的。有很多工具我們在那裏（只是谷歌的「網絡漏洞測試工具」開始...）
我曾與OWASP的ZED代理好經驗，在過去：https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
首先，我不同意Niki Driessen's answer。
我認爲，在一般的最佳安全做法是確保 含量設定爲「安全」時，它是由用戶，而不是當 你正在做它的東西產生。
這個聲明的問題是沒有上下文沒有「安全」的東西。
例如，取字符串<script>alert(1)</script>。
這是「安全」嗎？如果沒有在上下文中使用它，就不能回答這個問題。
例如，
<script>意味着什麼，以文本分析器。<script>將被瀏覽器解釋以啓動代碼執行上下文。爲了解決後一個問題，創建輸出頁面的過程應該將任何HTML特殊字符正確編碼爲實體格式（例如<script> ...）。
現在回到您的API問題。沒有特定的正確方法來做到這一點。
優勢返回原內容：
缺點：
優勢返回的HTML：
缺點：
這是一個讓您考慮可能的使用案例的決定。你可能有課程有多種方法，其中一些返回格式化的HTML，另一些則返回原始數據。格式化的HTML只有在通過預格式化輸出來增加值時纔有用。
*是的，這違背了我在我的答案的第一部分說，但是如果你是提供預渲染HTML 和讓用戶輸入HTML以在從返回的字段被渲染的客戶您API，那麼你必須充分過濾這個HTML，以確保沒有腳本輸入第一位。這是因爲您預先定義了要在HTML上下文中輸出的數據，而不是將其視爲原始數據。這比聽起來更詭計，因爲有很多方法可以將腳本輸入到HTML中（而不僅僅是<script>標籤）。如果您需要這樣做，請使用類似Google Caja的內容，而不是滾動自己的內容。
爲什麼不解碼iOS和Android客戶端中的HTML實體？ – Sumit
這也是一種可能性，但我的問題更多的是「是否有任何標準或慣例？」 – itsjavi