42道JavaWeb高頻題整理(附答案背誦版)

1、說一說Servlet的生命週期?

Servlet的生命週期主要由以下三個階段組成：初始化，服務和銷燬。

初始化（Initialization）: 當一個Servlet被載入到內存中時（例如，第一次訪問或者服務器啓動並且在web.xml中配置了load-on-startup），Servlet容器（例如Tomcat）就會調用Servlet的init()方法進行初始化。此方法在Servlet的生命週期中只被調用一次。
服務（Servicing）: 一旦Servlet被初始化，對其的每一次請求（例如HTTP請求）Servlet容器都會根據請求類型調用相應的方法（例如doGet(), doPost()等）。這個階段會重複執行，每次有新的請求時都會被調用。
銷燬（Destruction）: 當Servlet容器需要從內存中移除Servlet實例時（例如服務器關閉或者手動卸載Servlet），就會調用Servlet的destroy()方法。它也只在Servlet的生命週期中被調用一次。

舉一個應用場景的例子，假設我們有一個用於處理用戶登錄請求的LoginServlet。當服務器第一次啓動或者第一次收到登錄請求時，LoginServlet會被初始化，調用init()方法。然後，每當有用戶發送登錄請求時，LoginServlet就會調用 doPost()方法處理這個請求。最後，當服務器關閉或者我們不再需要LoginServlet時，就會調用destroy()方法，銷燬這個Servlet。

2、Servlet API中forward()與redirect()的區別？

forward() 和 redirect() 都是用於在服務器端處理請求後，將請求/響應轉發或重定向到另一個資源（例如另一個 Servlet，或者是一個 HTML 頁面等）的方法。但是，它們的工作方式和使用場景有些不同。

1. forward():

forward() 方法是在服務器端進行的，客戶端（瀏覽器）並不知道發生了轉發，所以瀏覽器的 URL 地址欄不會改變。
轉發是在服務器內部進行的，所以它更快，且不需要服務器和客戶端之間的額外通信。
當使用 forward() 方法時，請求對象和響應對象可以在資源之間共享，這意味着你可以在請求的屬性中設置數據，然後在被轉發的資源中獲取這些數據。

2. redirect():

redirect() 方法是通過向客戶端（瀏覽器）發送一個帶有新 URL 的響應來工作的，然後客戶端會向這個新 URL 發送一個新的請求。所以，瀏覽器的URL地址欄會顯示新的地址。
重定向需要服務器和客戶端之間的額外通信，所以它比轉發稍慢一些。
由於 redirect() 會導致新的請求，所以原始請求對象中的數據不會被保留。

舉個例子，假設有一個電子商務網站，用戶在瀏覽商品的時候，如果他們未登錄，我們可能會使用 forward() 方法將請求轉發到登錄頁面，因爲我們需要保留用戶原來的請求（即他們瀏覽的商品），以便在他們登錄後可以繼續處理。然而，如果用戶完成了購物，我們可能會使用 redirect() 方法將他們重定向到一個確認頁面，因爲我們希望這個確認頁面在瀏覽器的歷史記錄中有一個單獨的條目，這樣用戶就可以使用瀏覽器的後退按鈕返回到購物頁面，而不會再次提交購物請求。

3、request.getAttribute()和 request.getParameter()有何區別?

request.getAttribute() 和 request.getParameter() 是 Java Web 編程中常見的兩種方法，它們在 HTTP 請求處理中有着不同的用途和含義。

request.getParameter()：這個方法是用來獲取客戶端（通常是一個網頁表單）發送的參數。這些參數是通過 GET 或 POST 請求發送的。例如，如果您有一個登錄表單，其中包含用戶名和密碼字段，那麼您可以使用 request.getParameter("username") 和 request.getParameter("password") 來獲取這些字段的值。
request.getAttribute()：這個方法是用來從請求範圍（request scope）獲取對象的。當您在處理一個請求時，可以在請求範圍內設置對象，然後在稍後的處理階段或者在 JSP 頁面中獲取這些對象。例如，一個 Servlet 可以通過 request.setAttribute("data", data) 來設置一個名爲 "data" 的屬性，然後在 JSP 頁面中可以通過 ${data} 來獲取和顯示這個對象。

所以，主要的區別在於，getParameter() 是用來獲取客戶端發送的參數，而 getAttribute() 是用來在服務器端的請求處理過程中共享對象。

舉個例子，假設您有一個用來處理用戶登錄的 Servlet。用戶會從一個 HTML 表單中輸入他們的用戶名和密碼，然後這些信息會通過 POST 請求發送到您的 Servlet。在您的 Servlet 中，您可以使用 request.getParameter("username") 和 request.getParameter("password") 來獲取這些信息。然後，您可能會驗證這些信息，並根據驗證結果，將一些信息（如用戶對象或錯誤消息）放入請求範圍，以便在轉發到不同的 JSP 頁面時使用。這就是 request.setAttribute() 和 request.getAttribute() 的用途。

4、jsp靜態包含和動態包含的區別

在 JSP 中，包含操作可以是靜態的（也被稱爲編譯時包含）或動態的（也被稱爲運行時包含）。它們的主要區別在於包含操作發生的時間和方式。

靜態包含：靜態包含使用 JSP 指令 <%@ include file="file.jsp" %> 來實現。這種包含在 JSP 頁面編譯時發生。換句話說，被包含的 JSP 頁面的內容在編譯時就被插入到主 JSP 頁面中，然後作爲一個整體一起編譯。因此，如果被包含的頁面在包含後發生更改，這些更改將不會反映在主頁面上，除非主頁面重新編譯。
動態包含：動態包含使用 JSP 動作 <jsp:include page="file.jsp" /> 來實現。這種包含在請求處理期間，也就是運行時發生。每次請求主 JSP 頁面時，都會執行包含操作，並執行被包含的 JSP 頁面的代碼。因此，如果被包含的頁面在包含後發生更改，這些更改將會在下次請求主頁面時反映出來。

舉個例子，假設我們有一個網站的頭部和尾部是在所有頁面上都一樣的，我們可以用靜態包含將它們包含在每個頁面中。但是，如果我們有一個天氣小部件，它需要根據當前的天氣實時更新，那麼我們可能會選擇使用動態包含，以確保每次請求頁面時都能獲取最新的天氣信息。

5、MVC的各個部分都有那些技術來實現?如何實現?

MVC（Model-View-Controller）是一種設計模式，用於分離應用程序的數據訪問、用戶界面和業務邏輯，主要用於簡化應用程序的組織和實現。在 Java Web 開發中，通常使用以下技術來實現 MVC 設計模式：

Model（模型）：模型代表應用程序的數據和業務邏輯。它通常包含與數據庫交互的代碼，以及處理數據的算法和邏輯。在 Java Web 應用程序中，模型通常由 POJO (Plain Old Java Object) 類來實現，這些類通常與數據庫表一一對應。另外，數據訪問對象（DAO）和服務層也可以被看作是模型的一部分，用於封裝具體的數據庫操作和業務邏輯。

在 Java 中，我們可以使用各種 ORM 框架（如 Hibernate、MyBatis 等）來實現與數據庫的交互。
View（視圖）：視圖負責將模型的數據展示給用戶。在 Java Web 開發中，視圖通常由 JSP 或 Thymeleaf 這樣的模板引擎來實現。

例如，一個 JSP 頁面可能會使用 EL (Expression Language) 和 JSTL (JSP Standard Tag Library) 來訪問模型數據並將其呈現給用戶。
Controller（控制器）：控制器處理用戶的請求，調用模型的邏輯，並更新視圖。在 Java Web 開發中，控制器通常由 Servlet 或 Spring MVC 的 Controller 類來實現。

例如，一個 Servlet 可以接收用戶的請求，從請求中獲取參數，然後調用模型的方法來處理這些參數。處理完成後，Servlet 可以將結果存儲在請求或會話範圍的屬性中，然後轉發或重定向到一個 JSP 頁面，該頁面將使用這些結果來生成響應給用戶。

以下是一個簡單的示例，展示瞭如何使用 Servlet、JSP 和 POJO 類來實現 MVC 設計模式：

// Model
public class User {
    private String name;
    // getters and setters...
}

// Controller (Servlet)
@WebServlet("/user")
public class UserController extends HttpServlet {
    protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        User user = new User();
        user.setName("John");
        request.setAttribute("user", user);
        request.getRequestDispatcher("/user.jsp").forward(request, response);
    }
}

// View (JSP)
<%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%>
<html>
<body>
    User name: ${user.name}
</body>
</html>

在這個例子中，當用戶訪問 "/user" URL 時，UserController Servlet 會被執行。在 Servlet 中，我們創建了一個 User 對象，並將其設置爲請求範圍的屬性。然後，我們將請求轉發到 "user.jsp" 頁面，該頁面使用 EL 來訪問 "user" 屬性並將其顯示給用戶。

6、jsp有哪些內置對象?作用分別是什麼?

JSP 中有 9 個預定義的（內置的）對象，你可以在 JSP 頁面中直接使用它們，無需聲明。以下是這些對象以及它們的作用：
1. request：這是一個 HttpServletRequest 對象。這個對象包含了客戶端發送給服務器的請求信息，例如參數、頭信息、請求的 URL 等。
2. response：這是一個 HttpServletResponse 對象。使用這個對象，你可以控制發送給客戶端的響應，例如設置響應頭、設置響應狀態碼等。
3. pageContext：這是一個 PageContext 對象。這個對象提供了對其他幾個內置對象的訪問，同時提供了一些有用的頁面範圍的方法，例如用於獲取、設置和刪除屬性的方法。
4. session：這是一個 HttpSession 對象。這個對象用於在用戶的整個會話期間保存狀態信息。
5. application：這是一個 ServletContext 對象。這個對象允許你在整個應用程序範圍內共享數據。
6. out：這是一個 JspWriter 對象。這個對象用於輸出 HTML 到客戶端。
7. config：這是一個 ServletConfig 對象。這個對象包含了 Servlet 的初始化參數。
8. page：這是一個 Object 對象，代表了當前的 Servlet 實例。
9. exception：這是一個 Throwable 對象。這個對象只在使用 isErrorPage="true" 的錯誤頁面中可用，它包含了在當前頁面中拋出的異常。
這些內置對象爲你在處理 HTTP 請求時提供了很大的便利。例如，你可以使用 request 對象來獲取客戶端發送的參數，使用 session 對象來跟蹤用戶的會話狀態，使用 out 對象來發送 HTML 響應到客戶端，等等。

7、jsp 和 servlet 有什麼區別？

JSP (Java Server Pages) 和 Servlet 都是 Java Web 開發中常用的技術，它們都可以用於生成動態的 Web 內容。然而，它們在語法和用途上有一些重要的區別：

語法和易用性：JSP 是基於 HTML 的，它允許你在 HTML 代碼中嵌入 Java 代碼，這使得JSP 頁面非常適合於生成和展示視圖。JSP 支持表達式語言 (EL) 和 JSTL 標籤庫，這些功能使得在 JSP 頁面中訪問數據和執行常見操作變得非常簡單。另一方面，Servlet 是純 Java 的，你需要在 Servlet 中寫出完整的 Java 代碼來生成 HTML，這通常比在 JSP 中編寫代碼更爲複雜和冗長。
編譯方式：Servlet 在服務器啓動時或在接收到第一次請求時編譯，而且只編譯一次。但是，JSP 在接收到第一次請求時編譯，並且如果 JSP 文件被修改了，服務器會再次編譯它。這意味着你可以更新 JSP 文件並立即看到更改，而無需重新啓動服務器。
用途：由於上述的語法和易用性的差異，JSP 和 Servlet 通常被用於不同的目的。JSP 更適合於生成和展示視圖，也就是用戶看到的 HTML。Servlet 更適合於處理業務邏輯，例如處理表單提交、執行數據庫查詢等。

在實際開發中，JSP 和 Servlet 通常會一起使用，以實現 MVC (Model-View-Controller) 設計模式。在這種模式中，Servlet 作爲控制器，處理用戶的請求並執行業務邏輯；模型是由 POJO (Plain Old Java Object) 類來實現的，它們代表了應用程序的數據；JSP 作爲視圖，顯示模型的數據給用戶。

Session 和 Cookie 都是用於存儲用戶的狀態信息，但它們在許多方面都有所不同。以下是它們的主要區別：

存儲位置：Session 數據存儲在服務器端，每個用戶都有一個獨立的 Session。而 Cookie 存儲在客戶端（瀏覽器），服務器通過設置響應頭部信息將 Cookie 發送給客戶端。
存儲容量：由於 Cookie 數據存儲在客戶端，因此其存儲容量相對較小，通常不超過 4KB。而 Session 存儲在服務器端，理論上其存儲容量沒有限制，但過多的 Session 數據會佔用服務器的內存資源。
存儲類型：Cookie 只能存儲字符串類型的數據，並且需要對特殊字符進行編碼。而 Session 可以存儲任何類型的數據，包括字符串、數字、對象等。
生命週期：Cookie 有一個明確的過期時間，過期後 Cookie 數據將會被瀏覽器刪除。如果沒有設置過期時間，那麼 Cookie 僅在當前瀏覽器會話期間有效，關閉瀏覽器後 Cookie 就會被刪除。而 Session 的生命週期通常由服務器設置，當用戶在一段時間內沒有活動（如沒有發送新的請求）時，服務器會自動銷燬該用戶的 Session。
安全性：由於 Cookie 數據存儲在客戶端，因此其安全性相對較低，可能會被惡意用戶修改或竊取。而 Session 存儲在服務器端，用戶無法直接訪問，因此更安全。

總的來說，選擇使用 Session 還是 Cookie 主要取決於你的需求。如果你需要在客戶端存儲大量的數據，並且對安全性要求較高，那麼應該使用 Session。而如果你只需要存儲少量的數據，並且希望即使在用戶關閉瀏覽器後也能保持這些數據，那麼可以使用 Cookie。

9、Cookie的過期和Session的超時有什麼區別?

Cookie 和 Session 都是在 Web 開發中常用的會話技術，它們都可以用於在用戶的多次請求之間保存某些狀態信息。然而，Cookie 的過期和 Session 的超時代表的是兩種不同的概念：

Cookie 過期：
- Cookie 是存儲在客戶端的一小段數據。當我們創建一個 Cookie 時，我們可以設置一個 Max-Age 或者一個 Expires 屬性，來指定這個 Cookie 的生命週期。當這個 Cookie 的生命週期結束時，這個 Cookie 就會過期，瀏覽器會將其刪除。
- 例如，如果我們創建了一個 Max-Age 爲 3600 秒（1 小時）的 Cookie，那麼這個 Cookie 將在創建後的 1 小時後過期。無論用戶在這個 1 小時內做了什麼（無論是瀏覽其他頁面，還是關閉瀏覽器），只要這個 1 小時結束，這個 Cookie 就會過期。
Session 超時：
- Session 是存儲在服務器端的一組數據，每個用戶都有一個與之對應的 Session。Session 的超時，也就是 Session 的生命週期結束，通常是由於用戶在一段時間內沒有活動（例如，用戶沒有發送新的請求）。
- 例如，如果我們設置了 Session 的超時時間爲 30 分鐘，那麼如果用戶在 30 分鐘內沒有發送新的請求，這個 Session 就會超時。一旦用戶發送了新的請求，Session 的生命週期就會重置。

總的來說，Cookie 的過期是由 Cookie 的創建時間和 Max-Age 或 Expires 屬性決定的，而 Session 的超時是由用戶的最後一次活動和 Session 的超時設置決定的。

10、如何解決分佈式 Session 問題？

在分佈式系統中，Session 管理可能會成爲一個挑戰，因爲用戶的請求可能會被路由到不同的服務器上，而這些服務器需要共享 Session 信息。以下是解決分佈式 Session 問題的一些常見策略：

Session 複製：在這種方法中，每個服務器都有所有 Session 的副本。這意味着，無論請求被路由到哪個服務器，都能找到該 Session 的信息。這種方法的優點是，如果某個服務器出現故障，其他服務器仍可以處理請求。但是，這種方法可能會消耗大量的內存，並且在服務器之間同步 Session 信息也可能成爲性能瓶頸。
Session 粘性：在這種方法中，一旦用戶的請求被路由到某個服務器，後續的所有請求都將被路由到同一臺服務器。這樣，只有這臺服務器需要保存 Session 信息。這種方法的優點是簡單且效率高，但是，如果這臺服務器出現故障，用戶的 Session 信息將丟失。
集中 Session 存儲：在這種方法中，所有的 Session 信息都存儲在一個集中的數據存儲（例如，數據庫或者緩存服務器如 Redis）中。無論請求被路由到哪個服務器，都可以從這個集中的數據存儲中獲取 Session 信息。這種方法的優點是，可以很好地處理服務器的故障，但是，如果集中的數據存儲出現故障，所有的 Session 信息都可能丟失。
JWT（JSON Web Tokens）：JWT 是一種無狀態的解決方案，每次用戶請求都會攜帶一個簽名的 JSON 對象，該對象包含所有必要的信息。服務器驗證 JWT 的簽名，如果驗證通過，則處理請求。這種方法的優點是無需在服務器端存儲 Session 信息，可以很好地處理服務器的故障，但是，JWT 的大小通常比 Session ID 大，如果 JWT 包含了大量的數據，可能會影響網絡性能。

選擇哪種策略取決於具體的應用需求和環境，例如系統的可用性需求、系統的規模、網絡條件等。

單點登錄（Single Sign-On，SSO）是一種讓用戶只需登錄一次就可以訪問所有相關的系統或服務的方法。通常，這種方法依賴於 Cookie 來跟蹤用戶的登錄狀態。然而，如果 Cookie 被禁用了，我們可以考慮以下的替代方案：

URL 重寫：在每個 URL 後面附加一個 Session ID。這樣，即使 Cookie 被禁用，服務器仍然可以通過 URL 中的 Session ID 來識別用戶。但是，這種方法可能會引發安全問題，因爲 Session ID 可能會被截獲或者泄露，同時也可能破壞 URL 的美觀。
隱藏表單字段：在每個表單中添加一個隱藏的字段，用於存儲 Session ID。當用戶提交表單時，服務器可以從表單字段中獲取 Session ID。這種方法只適用於那些通過表單進行交互的應用。
使用 localStorage 或 sessionStorage：如果應用是基於 HTML5 的，那麼可以使用 Web Storage API 中的 localStorage 或 sessionStorage 來存儲 Session ID。這兩者都是在客戶端存儲數據的方法，和 Cookie 不同的是，它們不會隨着每次請求自動發送到服務器，而需要通過 JavaScript 明確地讀取和發送。
使用其他認證方法：例如，可以使用基於令牌的認證方法，如 JWT（JSON Web Tokens）。在這種方法中，服務器生成一個包含用戶身份信息的令牌，並將其發送給客戶端。客戶端將此令牌存儲起來，並在每次請求時將其包含在請求頭中。服務器通過驗證此令牌來識別用戶。

以上這些方法都有其優點和缺點，選擇哪種方法取決於具體的應用需求和環境。例如，如果應用需要高安全性，那麼可能需要避免使用 URL 重寫；如果應用是基於 HTML5 的，那麼可能可以考慮使用 localStorage 或 sessionStorage。

12、session何時被刪除？

在 Web 開發中，一個 Session 對象何時被刪除（或稱爲 Session 失效）主要取決於以下幾個因素：

Session 超時：大多數 Web 應用框架都允許你設置一個 Session 的超時時間。如果在這個時間段內，服務器沒有收到來自特定 Session 的任何請求，那麼這個 Session 就會被自動刪除。在 Java Servlet 中，你可以在 web.xml 配置文件中通過 <session-config> 元素來設置 Session 的超時時間。
手動刪除：你的應用程序代碼可以顯式地刪除一個 Session。例如，在 Java Servlet 中，你可以調用 HttpSession.invalidate() 方法來立即刪除一個 Session。
服務器重啓：如果你的 Web 服務器或應用服務器重啓，那麼存儲在內存中的所有 Session 通常都會被刪除。然而，一些服務器可以配置爲在重啓時將 Session 信息保存到磁盤，並在重啓後從磁盤重新載入 Session 信息。
瀏覽器關閉：如果 Session 是基於 Cookie 實現的（這是最常見的實現方式），那麼當用戶關閉瀏覽器時，與 Session 關聯的 Cookie 通常會被刪除（除非你將 Cookie 設置爲持久化 Cookie）。然而，這並不會直接導致 Session 在服務器端被刪除，除非服務器設置了 Session 超時。

注意，Session 的管理是 Web 應用服務器的責任，不同的服務器可能會有不同的 Session 管理策略。例如，一些服務器可能會定期檢查並刪除超時的 Session，而其他服務器可能會在收到新請求時檢查 Session 的超時狀態。

13、tomcat容器是如何創建servlet類實例？用到了什麼原理？

Tomcat 是一個實現了 Servlet 規範的 Web 容器。它負責創建和管理 Servlet 的生命週期，包括實例化 Servlet、調用其初始化方法和服務方法，以及調用其銷燬方法。

以下是 Tomcat 創建 Servlet 實例的過程：

加載 Servlet 類：當 Tomcat 收到一個請求並確定需要使用某個特定的 Servlet 來處理請求時，它會使用類加載器（ClassLoader）來加載對應的 Servlet 類。如果這個 Servlet 類已經被加載過，那麼就會跳過這個步驟。
實例化 Servlet 類：Tomcat 使用 Java 的 newInstance 方法來創建 Servlet 類的一個新實例。這個方法調用了 Servlet 類的無參構造函數。如果 Servlet 類沒有無參構造函數，或者構造函數不可訪問（例如，構造函數是私有的），那麼 newInstance 方法會拋出一個異常。
初始化 Servlet 實例：Tomcat 調用了 Servlet 實例的 init 方法來初始化這個 Servlet。init 方法接收一個 ServletConfig 對象作爲參數，這個對象包含了 Servlet 的初始化參數。
調用服務方法：在 Servlet 初始化完成後，Tomcat 會調用 Servlet 的 service 方法來處理請求。service 方法接收兩個參數：一個 HttpServletRequest 對象和一個 HttpServletResponse 對象。這兩個對象分別代表了客戶端的請求和服務器的響應。

以上步驟中提到的 newInstance 方法，是 Java 反射（Reflection）的一部分。Java 反射允許程序在運行時訪問和操作類和對象的內部信息，包括類的字段、方法和構造函數。在這個場景下，反射使得 Tomcat 能夠在不知道 Servlet 類的具體類型的情況下，創建 Servlet 類的實例。

需要注意的是，Servlet 是單例的，即對於每個 Servlet 類，Tomcat 只會創建一個實例。這個實例會被多個線程共享，每個線程代表一個客戶端的請求。因此，Servlet 必須是線程安全的。

14、如何避免 sql 注入？

SQL注入是一種常見的網絡攻擊方式，攻擊者通過在查詢語句中插入惡意的SQL代碼，以獲取敏感信息或對數據庫進行操作。爲了避免SQL注入，通常有以下幾種方法：

預編譯語句（Prepared Statements）：這種方法是在執行SQL語句之前，先確定好SQL的執行格式，然後再把參數傳入。由於參數不會被解釋爲SQL指令，因此可以防止SQL注入。在Java中，可以使用PreparedStatement對象來實現預編譯語句。

String selectSQL = "SELECT * FROM Users WHERE username = ? AND password = ?";
PreparedStatement preparedStatement = connection.prepareStatement(selectSQL);
preparedStatement.setString(1, "user");
preparedStatement.setString(2, "password");
ResultSet resultSet = preparedStatement.executeQuery();

參數化查詢（Parameterized Queries）：參數化查詢與預編譯語句類似，也是先確定SQL語句的格式，然後再傳入參數。這種方法也可以有效防止SQL注入。
過濾用戶輸入（Input Validation）：在處理用戶輸入的信息之前，檢查並過濾其中可能存在的惡意內容。例如，可以限制用戶名只能由字母和數字組成。
最小權限原則（Principle of Least Privilege）：對數據庫的操作權限進行嚴格的控制，讓每個用戶只擁有其需要的最小權限，這樣即使發生SQL注入，攻擊者也無法執行非法的操作。

請注意，以上方法最好同時使用，以提供更強的安全保護。

15、什麼是 XSS 攻擊，如何避免？

XSS（Cross-Site Scripting）攻擊是一種在網頁上注入惡意腳本，使之在其他用戶的瀏覽器上運行的攻擊方式。當用戶瀏覽這個含有惡意腳本的網頁時，惡意腳本就會在用戶的瀏覽器上執行，從而進行各種惡意操作，如竊取用戶信息，篡改網頁內容等。

以下是幾種常用的防止XSS攻擊的方法：

轉義用戶輸入：對所有用戶輸入的數據進行轉義處理（escaping），使得這些內容被瀏覽器解析爲純文本，而不是腳本代碼。例如，可以把字符<和>轉義爲<和>，這樣就可以防止惡意用戶提交含有腳本的內容。
內容安全策略（Content Security Policy, CSP）：CSP是一種瀏覽器安全機制，可以限制網頁加載和執行的資源。例如，可以設置CSP只允許加載和執行來自於當前域名的腳本，這樣就可以有效防止XSS攻擊。
輸入驗證：對所有用戶輸入的數據進行驗證，檢查是否含有可能引發XSS攻擊的字符或字符串，如<script>等，如果有，就拒絕接受。
使用HTTP-only Cookies：將敏感的會話cookie設置爲HTTP-only，這樣JavaScript就無法讀取到cookie。即便XSS攻擊發生，攻擊者也無法竊取這些cookie。
避免使用不安全的API：部分JavaScript API，如eval，document.write，innerHTML，outerHTML等，可能會導致XSS攻擊，應儘量避免使用。