只有在與較舊的系統進行通訊且無法使用更高等級的通訊協定時，J2EE 標準才會允許 Use of Sockets。自己編寫通訊協定將需要解決許多安全上的問題，其中包括：

- 輸入信號與輸出信號的比較

- 通訊協定版本間的相容性

- 通道安全性

- 錯誤處理

- 網路條件約束 (防火牆)

- 階段作業管理

除非經過安全專家的仔細檢查，否則自訂的通訊協定會面臨很多安全性問題。

在執行自訂的標準通訊協定時，也會遇到許多相同的問題。通常有很多可用資源都可以解決執行標準通訊協定時會遇到的安全性問題，但是，攻擊者也可取得這些資源。

在某些情況下，J2EE 標準會禁止在 Web 應用程式中進行執行緒管理，且執行緒管理非常容易發生錯誤。管理執行緒非常困難，並且可能會以無法預測的方式干擾應用程式容器的運作。即使容器沒有受到干擾，執行緒管理通常還是會發生錯誤，例如無法偵測並診斷鎖死 (deadlock)、Race Condition 及其他同步錯誤。

多數 Web 應用程式使用工作階段識別碼來識別各使用者，該識別碼通常儲存在 Cookie 中，並在伺服器與網路瀏覽器間公開傳輸。


未在 Cookie 中儲存工作階段識別碼的應用程式，有時會傳輸識別碼做為 HTTP 要求參數或 URL 的一部份。接受 URL 中指定的工作階段識別碼，容易讓攻擊者執行 Session Fixation 攻擊。

將工作階段識別碼置於 URL，也可能會增加 Session Hijacking 對應用程式成功攻擊的機會。當攻擊者控制受害者啟用的工作階段或工作階段識別碼時，Session Hijacking 便會發生。網路伺服器、應用程式伺服器及 Web 代理伺服器通常會儲存要求的 URL，這是種常見的作法。若 URL 中包含工作階段識別碼，也會記錄這些識別碼。增加工作階段識別碼檢視及儲存位置的數量，將增加攻擊者危及這些識別碼的機會。

如果您使用 Tomcat 來執行 authentication，Tomcat 部署描述符號檔案會指定「Realm」用於 Authentication。內容將與下列相似：

範例 1：

  <Realm className="org.apache.catalina.realm.JAASRealm"
         appName="SRN"
         userClassNames="com.srn.security.UserPrincipal"
         roleClassNames="com.srn.security.RolePrincipal"/>

此 Realm 標籤有一個名為 debug 的選擇性屬性，由它來指示記錄層級。數字越大，記錄的訊息就越詳細。如果除錯層級設定過高，Tomcat 會把所有的使用者名稱和密碼以純文字方式寫入至記錄檔中。Tomcat JAASRealm 相關的除錯訊息的臨界值是 3 (3 或更高表示有問題，2 或更低表示正常)，但此臨界值可能會因 Tomcat 提供不同的 realm 類型而有所不同。

在使用 Web 架構，例如 Struts 或 Spring (使用動作或 Servlet 對 JSP 發出請求) 所建立的應用程式中，直接存取 Java Server Page (JSP)，可能會導致無法處理的異常以及系統資訊洩露。執行或設定不當的應用程式伺服器已被用來洩露原始碼詳細資料，使用的手段則包括 http://host/page.jsp%00 或 http://host/page.js%2570 等精心設計的要求。更糟的是，如果應用程式允許使用者上傳任意檔案，攻擊者可能使用此機制，上傳以 JSP 型式製作的惡意程式碼，並要求已上傳頁面，以在伺服器上執行惡意程式碼。

範例 1：以下範例說明建構不良的安全性限制，明確允許角色名稱中含有「*」直接存取 JSP，因此，這表示所有使用者都可以存取對應的 Web 資源。

<security-constraint>
    <web-resource-collection>
        <web-resource-name>JSP Access for Everyone!</web-resource-name>
        <description>Allow any user/role access to JSP</description>
        <url-pattern>*.jsp</url-pattern>
    </web-resource-collection>
    <auth-constraint>
        <role-name>*</role-name>
    </auth-constraint>
</security-constraint>

相同的安全性角色並無意義，因為只會套用特定安全性角色的最後定義。
範例 1：在 web.xml 檔案中的項目定義了兩個 admin 角色。

<security-constraint>
    <web-resource-collection>
        <web-resource-name>AdminPage</web-resource-name>
        <description>Admin only pages</description>
        <url-pattern>/auth/noaccess/*</url-pattern>
    </web-resource-collection>
    <auth-constraint>
        <description>Administrators only</description>
        <role-name>admin</role-name>
    </auth-constraint>
</security-constraint>
...
<security-role>
    <description>Administrator</description>
    <role-name>admin</role-name>
</security-role>

<security-role>
    <description>Non-Administrator</description>
    <role-name>admin</role-name>
</security-role>

相同的 Servlet 對應是沒有意義的，因為在多個 Servlet 對應中使用相同 URL 模式時，只會套用最後一個項目。

範例 1：在以下範例中，兩個不同的 Servlet 對應中使用 URL 模式 /servletA/*。

<servlet-mapping>
    <servlet-name>ServletA</servlet-name>
    <url-pattern>/servletA/*</url-pattern>
</servlet-mapping>
<servlet-mapping>
    <servlet-name>ServletB</servlet-name>
    <url-pattern>/servletA/*</url-pattern>
</servlet-mapping>

多個 URL 模式對應至單一 Servlet，可能代表該 Servlet 執行了太多功能。

範例 1：以下範例將五個 URL 模式對應至單一 Servlet。

<servlet>
    <servlet-class>com.class.MyServlet</servlet-class>
    <load-on-startup>1</load-on-startup>
</servlet>

<servlet-mapping>
    <servlet-name>MyServlet</servlet-name>
    <url-pattern>/myservlet</url-pattern>
</servlet-mapping>

<servlet-mapping>
    <servlet-name>MyServlet</servlet-name>
    <url-pattern>/helloworld*</url-pattern>
</servlet-mapping>

<servlet-mapping>
    <servlet-name>MyServlet</servlet-name>
    <url-pattern>/servlet*</url-pattern>
</servlet-mapping>

<servlet-mapping>
    <servlet-name>MyServlet</servlet-name>
    <url-pattern>/mservlet*</url-pattern>
</servlet-mapping>

<servlet-mapping>
    <servlet-name>MyServlet</servlet-name>
    <url-pattern>/*</url-pattern>
</servlet-mapping>

開啟工作階段時間愈久，攻擊者威脅使用者帳戶的機率就愈大。工作階段仍為作用中時，攻擊者可能會暴力破解使用者密碼、破解使用者的無線加密金鑰，或是從開啟的瀏覽器控制工作階段。如果足夠大量的工作階段正在執行，較長的工作階段逾時時間也會導致無法釋放記憶體，最後造成阻斷服務。

範例 1：如果工作階段逾時時間為零或小於零，該工作階段永遠不會過期。以下範例顯示工作階段逾時時間設定為 -1，就會無限期保留工作階段為作用中。

<session-config>
    <session-timeout>-1</session-timeout>
</session-config>

<session-timeout> 標籤定義 Web 應用程式中，所有工作階段的預設逾時時間間隔。如果沒有 <session-timeout> 標籤，就會交由容器來設定預設逾時時間。

當攻擊者瀏覽網站尋找弱點時，網站所提供的資訊數量是任何攻擊的成敗關鍵。如果應用程式向攻擊者顯示堆疊追蹤的資訊，其所釋出的資訊使攻擊者的攻擊變得輕而易舉。例如，堆疊追蹤可能顯示下列資訊給攻擊者：SQL 查詢語句、使用的程式庫類型、應用程式容器的版本。攻擊者可以從這些資訊中找到這些元件的弱點。

因此，應用程式組態應指定預設錯誤頁面以確保應用程式不會向攻擊者洩漏錯誤訊息。處理標準 HTTP 錯誤程式碼是簡單、有用、安全的作法，完善的組態還會定義用於補救的錯誤處理器，來捕捉應用程式可能會拋出的所有異常。

如果應用程式使用 SSL 來確保與用戶端瀏覽器之間的機密通訊，那麼應用程式組態應該規定如未使用 SSL，就無法查看任何存取控制的頁面。

通常有以下三種方式可略過 SSL：

- 使用者手動輸入 URL，且輸入「HTTP」而不是「HTTPS」。

- 攻擊者有意的將使用者傳送到不安全的 URL。

- 程式設計師在應用程式中錯誤的建立了相關頁面的連結，使其未能從 HTTP 轉換成 HTTPS。(這種情況很容易發生，尤其在網站中的公用和安全區域之間的連結移動。)

WebLogic 部署描述符號至少應該指定長度 24 位元組的工作階段識別碼。長度較短的工作階段識別碼會使應用程式暴露於暴力破解的攻擊下。如果攻擊者可以猜測出驗證使用者的工作階段識別碼，他就能夠控制使用者的工作階段。以下的解釋將詳細說明 24 位元組工作階段識別碼的合理性。

階段作業識別碼是由 62 個英數字元所組成的虛擬隨機亂數，這表示，如果字串真的是隨機組成的，則每個位元組最高能產生 6 位元的複雜度。

以下方程式提供猜測有效的工作階段識別碼所需的秒數：

(2^B+1) / (2*A*S)

其中：

- B 是工作階段識別碼中複雜度 (entropy) 的位元數。

- A 表示攻擊者每秒可能嘗試猜測的次數。

- S 是指在任何時間內可供猜測的有效工作階段識別碼數目。

工作階段識別碼中的複雜度 (entropy) 位元數比工作階段識別碼的總位元數要少。例如，如果以遞增的次序提供工作階段識別碼，則不管識別碼的長度如何，在工作階段識別碼中會有接近於 0 位元的複雜度 (entropy)。假設工作階段識別碼是使用好的隨機數字來源所產生，我們估算工作階段識別碼中複雜度 (entropy) 的位元數將是總工作階段識別碼位元數的一半。以樂觀態度來看，有可能存在此長度的識別碼。

如果攻擊者使用成千上百個受感染的電腦組成的僵屍電腦網路 (botnet)，那麼他們可進行每秒幾萬次的猜測。如果此問題網站很大而且很多人點閱，有時可能會忽略其大量的猜測行為。

可供猜測的有效工作階段識別碼數量的較低界線為，在任何時間內於網站上活動的使用者數量。不過，任何沒有登出就離開工作階段的使用者將會使此數目增加。(這就是為什麼要將未活動工作階段逾時時間設短一點的原因之一。)

使用 64 位元的工作階段識別碼，假設會有 32 位元的複雜度。對於大型網站，假設攻擊者每秒可能嘗試猜測 1000 次，並且在任何給定時間有 10000 個有效的工作階段識別碼。根據這些假設，攻擊者成功猜到有效的工作階段識別碼的預估時間大約在 4 分鐘以內。

現在假設使用 128 位元的工作階段識別碼，提供 64 位元的複雜度。對於超大型網站，攻擊者在 100000 個可猜測的有效工作階段識別碼中可以嘗試每秒 10000 次的猜測。根據這些假設，攻擊者成功猜到有效的工作階段識別碼的預估時間將超過 292 年。

將位元換成位元組，則工作階段識別碼為 128/6，大約產生 21 個位元組。此外，實驗顯示，工作階段識別碼的前三個位元組不是隨機產生的，這表示要達到想要的 64 位元的複雜度 (entropy)，我們需要將 WebLogic 設定為使用長度為 24 位元組的工作階段識別碼。

web.xml 中，沒有 Servlet 名稱或是有相同的 Servlet 名稱，視為錯誤。每個 Servlet 應該擁有專屬名稱 (servlet-name ) 以及相符的對應 (servlet-mapping)。

範例 1：以下 web.xml 中的項目顯示了數個錯誤 Servlet 定義。

<!-- No <servlet-name> specified: -->
    <servlet>
        <servlet-class>com.class.MyServlet</servlet-class>
        <load-on-startup>1</load-on-startup>
    </servlet>

<!-- Empty <servlet-name> node: -->
    <servlet>
        <servlet-name/>
        <servlet-class>com.class.MyServlet</servlet-class>
        <load-on-startup>1</load-on-startup>
    </servlet>

<!-- Duplicate <servlet-name> nodes: -->
    <servlet>
        <servlet-name>MyServlet</servlet-name>
        <servlet-name>Servlet</servlet-name>
        <servlet-class>com.class.MyServlet</servlet-class>
        <load-on-startup>1</load-on-startup>
    </servlet>

這些錯誤可能會造成意外拒絕存取 Servlet。

使用 <login-config> 元素來設定使用者驗證至應用程式的方式。因為沒有人可以登入，沒有 authentication 方式就表示該應用程式不知道套用授權限制的方式。Authentication 方式是使用 <auth-method> 標籤進行指定，該標籤也是 <login-config> 的子項。

Authentication 方式共有四種：BASIC、FORM、DIGEST 和 CLIENT_CERT。

BASIC 代表 HTTP Basic 驗證。
FORM 代表表單架構驗證。
DIGEST 與 BASIC 驗證類似，但在 DIGEST 中，會將密碼加密。
CLIENT_CERT 要求用戶端擁有公開金鑰憑證並使用 SSL/TLS。

範例 1：以下組態並未指定登入組態。

<web-app>

    <!-- servlet declarations -->
    <servlet>...</servlet>

    <!-- servlet mappings-->
    <servlet-mapping>...</servlet-mapping>

    <!-- security-constraints-->
    <security-constraint>...</security-constraint>

    <!-- login-config goes here -->

    <!-- security-roles -->
    <security-role>...</security-role>

</web-app>

web.xml 安全性限制通常用來做為角色為基礎的 Access Control 使用，但是選用的 user-data-constraint 元素會指定傳輸保證，避免以不安全的方式傳輸內容。

在 <user-data-constraint> 標籤內，<transport-guarantee> 標籤會定義應該如何處理通訊。傳輸保證共有三個層級：

1) NONE 表示應用程式不需要任何傳輸保證。
2) INTEGRAL 表示應用程式需要用戶端和伺服器之間使用此方法傳送資料，如此一來在傳輸資料時就不會變更。
3) CONFIDENTIAL 表示應用程式會要求要以避免其他實體可檢視傳輸內容的方式來傳送資料。



在大部分情況中，使用 INTEGRAL 或 CONFIDENTIAL 就表示必須使用 SSL/TLS。如果省略了 <user-data-constraint> 和 <transport-guarantee> 標籤，傳輸保證會預設為 NONE。

範例 1：以下安全性限制不會指定傳輸保證。

<security-constraint>
    <web-resource-collection>
        <web-resource-name>Storefront</web-resource-name>
        <description>Allow Customers and Employees access to online store front</description>
        <url-pattern>/store/shop/*</url-pattern>
    </web-resource-collection>
    <auth-constraint>
        <description>Anyone</description>
        <role-name>anyone</role-name>
    </auth-constraint>
</security-constraint>

當攻擊者瀏覽網站尋找弱點時，網站所提供的資訊數量是任何攻擊的成敗關鍵。如果應用程式向攻擊者顯示堆疊追蹤的資訊，其所釋出的資訊使攻擊者的攻擊變得輕而易舉。例如，堆疊追蹤可能顯示下列資訊給攻擊者：SQL 查詢語句、使用的程式庫類型、應用程式容器的版本。攻擊者可以從這些資訊中找到這些元件的弱點。

因此，應用程式組態應指定預設錯誤頁面以確保應用程式不會向攻擊者洩漏錯誤訊息。處理標準 HTTP 錯誤程式碼是簡單、有用、安全的作法，完善的組態還會定義用於補救的錯誤處理器，來捕捉應用程式可能會拋出的所有異常。

每個篩選對應必須對應至有效的篩選定義，才可以進行套用。

範例 1：以下範例說明參照不存在篩選 AuthenticationFilter 的篩選對應。因為缺少定義，不會套用篩選 AuthenticationFilter 至指定的 URL 模式 /secure/* 上，而且可能會造成執行階段異常。

<filter>
    <description>Compresses images to 64x64</description>
    <filter-name>ImageFilter</filter-name>
    <filter-class>com.ImageFilter</filter-class>
</filter>

<!-- AuthenticationFilter is not defined -->
<filter-mapping>
    <filter-name>AuthenticationFilter</filter-name>
    <url-pattern>/secure/*</url-pattern>
</filter-mapping>

<filter-mapping>
    <filter-name>ImageFilter</filter-name>
    <servlet-name>ImageServlet</servlet-name>
</filter-mapping>

沒有 auth-constraint 中所定義 role-name 的 security-role 可能表示該組態已過時。

範例 1：以下範例指定一個 role-name，但並未在 security-role 中定義該角色名稱。

<security-constraint>
    <web-resource-collection>
         <web-resource-name>AdminPage</web-resource-name>
         <description>Admin only pages</description>
         <url-pattern>/auth/noaccess/*</url-pattern>
    </web-resource-collection>

    <auth-constraint>
        <description>Administrators only</description>
        <role-name>admin</role-name>
    </auth-constraint>

    <user-data-constraint>
        <transport-guarantee>INTEGRAL</transport-guarantee>
    </user-data-constraint>
</security-constraint>

沒有有效的 Servlet 對應，會導致無法存取所有未對應 Servlet。

範例 1：以下 web.xml 中的項目會定義 ExampleServlet，但無法定義相符的 Servlet 對應。

<web-app
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"
    version="2.4">

    <servlet>
      <servlet-name>ExampleServlet</servlet-name>
      <servlet-class>com.class.ExampleServlet</servlet-class>
      <load-on-startup>1</load-on-startup>
    </servlet>

</web-app>

實體 bean 所暴露的遠端介面會成為應用程式攻擊介面的一部分。由於效能方面的考量，應用程式幾乎不使用遠端實體 bean。因此，遠端實體 bean 的宣告有可能是個錯誤。

範例 1：以下對實體 bean 的宣告包含了遠端介面：

<ejb-jar>
<enterprise-beans>
<entity>
<ejb-name>EmployeeRecord</ejb-name>
<home>com.wombat.empl.EmployeeRecordHome</home>
<remote>com.wombat.empl.EmployeeRecord</remote>
...
</entity>
...
</enterprise-beans>
</ejb-jar>