<exception> 標籤要求定義例外類型。缺少或空白的 type 屬性表示有多餘的異常處理器或是意外的省略。如果開發人員想要處理異常，但忘記定義異常類型，應用程式就可能洩露系統的敏感資訊。
範例 1：以下組態省略 <exception> 標籤的類型。

  <global-exceptions>
    <exception
      key="error.key"
      handler="com.mybank.ExceptionHandler"/>
  </global-exceptions>

Struts 使用 form-bean 項目進行 HTML 型式與動作的對應。如果 <action> 標籤中的 name 屬性無法與 form-bean 的名稱對應，就無法對應該動作，並且表示該項目為不必要的定義或拼字錯誤。

範例 1：以下組態不包含 bean2 的對應。

<form-beans>
  <form-bean name="bean1" type="coreservlets.UserFormBean" />
</form-beans>

<action-mappings>
  <action path="/actions/register1" type="coreservlets.RegisterAction1" name="bean1" scope="request" />
  <action path="/actions/register2" type="coreservlets.RegisterAction2" name="bean2" scope="request" />
</action-mappings>

Struts 使用 form-bean 名稱進行 HTML 型式與動作的對應。如果 form-bean 沒有名稱，就無法對應至動作，這表示該項目為不必要的定義或是意外省略的 Bean。
此為正確的 Form-Bean 範例：
範例 1：以下 form-bean 有一項空的 name 屬性。

<form-beans>
  <form-bean name="" type="org.apache.struts.validator.DynaValidatorForm">
    <form-property name="name" type="java.lang.String" />
    <form-property name="password" type="java.lang.String" />
  </form-bean>
</form-beans>

Struts 使用 form-bean 項目進行 HTML 型式與動作的對應。如果 form-bean 沒有類型，就無法對應至動作。
範例 1：以下 form-bean 有一項空的 type 屬性。

<form-beans>
  <form-bean name="loginForm" type="">
    <form-property name="name" type="java.lang.String" />
    <form-property name="password" type="java.lang.String" />
  </form-bean>
</form-beans>

Struts 要求 <form-property> 標籤必須包括 type 屬性。處理定義沒有類型的 form-property 的表單時，Struts 將會拋出異常。

範例 1：以下組態省略 name 屬性的類型。

<form-bean name="loginForm" type="org.apache.struts.validator.DynaValidatorForm">
  <form-property name="name" />
  <form-property name="password" type="java.lang.String" />
</form-bean>

<forward> 標籤必須有 name 和 path 屬性。沒有名稱的話，就永遠不會使用 forward。

範例 1：以下 <forward> 標籤有一項空的 name 屬性。

    <forward name="" path="/results.jsp"/>

<forward> 標籤必須有 name 和 path 屬性。省略路徑或指定一個空白路徑皆視為錯誤。此外，所有路徑都必需以「/」字元開頭。

範例 1：以下 <forward> 標籤缺少 path 屬性。

    <forward name="success" />

如果兩個驗證表單具有相同的名稱，Struts Validator 會任意選擇一個表單來進行輸入驗證，而放棄另外一個。這可能不是程式設計師所期望的。而且，這表示沒有維護驗證邏輯，並表示可能存在其他未察覺的驗證錯誤。

範例 1：具有相同名稱的兩個驗證表單。

<form-validation>
    <formset>
        <form name="ProjectForm">
        ...
        </form>
        <form name="ProjectForm">
        ...
        </form>
    </formset>
</form-validation>

維護驗證邏輯，並與應用程式的其他部分保持同步化是非常重要的。未經檢查的輸入是導致目前最糟糕、最常見的軟體安全問題的根源。Cross-site scripting、SQL injection 和 process control 的弱點是由於缺少輸入驗證或輸入驗證不完整而造成的。雖然 J2EE 應用程式在通常情況下不容易因記憶體損壞攻擊而受到影響，但是如果 J2EE 應用程式連接到未執行陣列界限檢查的本地程式碼，攻擊者就能夠在 J2EE 應用程式中利用輸入驗證錯誤發起 Buffer overflow 攻擊。

Struts Validator 使用表單的 validate() 方法，對照那些在相關驗證表單中定義的約束來檢查表單屬性的內容。這表示以下這些類別擁有一個 validate() 方法，該方法是屬於驗證框架的一部分：

    ValidatorForm
    ValidatorActionForm
    DynaValidatorForm
    DynaValidatorActionForm

如果您要建立一個由以上類別所延伸的類別，且您的類別覆蓋了 validate() 方法而執行自訂的驗證邏輯，則您必須在 validate() 執行中呼叫 super.validate()。如果您不這麼做，驗證框架就不能對照驗證表單驗證表單中的內容。也就是說，會針對該提供的表單而停用驗證框架。

對表單來說，停用驗證框架會使應用程式暴露在各種的攻擊之下。未經驗證的輸入是導致各種弱點的根源，如 cross-site scripting、process control 和 SQL injection。雖然 J2EE 應用程式在通常情況下不容易因損壞記憶體而受到影響，但是如果 J2EE 應用程式連接到未執行陣列界線檢查的本地程式碼，攻擊者就能夠在 J2EE 應用程式中利用輸入驗證錯誤發起 Buffer overflow 攻擊。

為了能夠使用 Struts Validator，表單必須延伸以下其中一個項目：

ValidatorForm
ValidatorActionForm
DynaValidatorActionForm
DynaValidaorForm

您必須延伸這些類別中的其中一個，因為 Struts Validator 是透過在這些類別中執行 validate() 方法，而與應用程式連結。

源自下面類別的表單不能使用 Struts Validator：

ActionForm
DynaActionForm

略過表單的驗證框架將使應用程式暴露於各種攻擊之下。未經驗證的輸入是導致各種弱點的根源，如 cross-site scripting、process control 和 SQL injection。雖然 J2EE 應用程式在通常情況下不容易因記憶體損壞攻擊而受到影響，但是如果 J2EE 應用程式連接到未執行陣列界限檢查的本地程式碼，攻擊者就能夠在 J2EE 應用程式中利用輸入驗證錯誤發起 Buffer overflow 攻擊。

只要疏忽了一個輸入欄位的驗證，就會留下攻擊者能利用的破綻。

未經檢查的輸入是導致目前最糟糕、最常見的軟體安全問題的根源。Cross-site scripting、SQL injection 和 process control 的弱點是由於缺少輸入驗證或輸入驗證不完整而造成的。雖然 J2EE 應用程式在通常情況下不容易因記憶體損壞攻擊而受到影響，但是如果 J2EE 應用程式連接到未執行陣列界限檢查的本地程式碼，攻擊者就能夠在 J2EE 應用程式中利用輸入驗證錯誤發起 Buffer overflow 攻擊。

某些應用程式使用相同的 ActionForm 來實行多個用途。在這種情況下，某些欄位在某些操作對應中可能會沒有使用。對沒有使用的欄位也進行驗證是很重要的。最好是對沒有使用的欄位進行嚴格控制，讓它們只能處於空白或未定義的狀態。如果沒有使用的欄位沒有經過驗證，操作中的共用商業邏輯可能會允許攻擊者略過針對表單其他應用所進行的驗證檢查。

在 J2EE 應用程式中，未經檢查的輸入是弱點產生的主因。未經檢查的輸入資料會導致許多弱點的產生，包括 Cross-Site Scripting、Process Control 和 SQL injection。雖然 J2EE 應用程式在通常情況下不容易因記憶體損壞攻擊而受到影響，但是如果 J2EE 應用程式連接到未執行陣列界限檢查的本地程式碼，攻擊者就能夠在 J2EE 應用程式中利用輸入驗證錯誤發起 Buffer overflow 攻擊。

若要避免此類攻擊，應在應用程式處理輸入資料之前使用 Struts Validator 來檢查所有程式的輸入。使用 Fortify Static Code Analyzer 來確保 Struts Validator 的組態不存在任何弱點。

驗證器的範例用法包括進行檢查並確保：

- 電話號碼欄位只包含電話號碼中的有效字元

- Boolean 值只有「T」或「F」

- 未限定格式的字串必須有合理的長度，並且由有效的字元組成

Struts 使用 form-bean 項目進行 HTML 型式與動作的對應。如果 Struts 組態設定檔案的 <action-mappings> 元素不包含對應經由 <form-bean> 標籤所定義的相關操作表單的項目，應用程式邏輯可能已過時。

範例 1：以下組態不包含 bean2 的對應。

<form-beans>
  <form-bean name="bean1" type="coreservlets.UserFormBean1" />
  <form-bean name="bean2" type="coreservlets.UserFormBean2" />
</form-beans>

<action-mappings>
  <action path="/actions/register1" type="coreservlets.RegisterAction1" name="bean1" scope="request" />
</action-mappings>

當開發人員移除或重新命名操作表單對應後，很容易忘記去更新驗證邏輯。存在 Unused Validation Form，是驗證邏輯未受到適當維護的一個跡象。

如果 Struts Action Form Mapping 指定了一個表單，它必須具有一個在 Struts Validator 下定義的驗證表單。如果操作表單對應沒有定義驗證表單，它可能會容易受到那些利用未經檢查的輸入所發起的攻擊。

未經檢查的輸入是導致目前最糟糕、最常見的軟體安全問題的根源。Cross-site scripting、SQL injection 和 process control 的弱點是由於缺少輸入驗證或輸入驗證不完整而造成的。雖然 J2EE 應用程式在通常情況下不容易因記憶體損壞攻擊而受到影響，但是如果 J2EE 應用程式連接到未執行陣列界限檢查的本地程式碼，攻擊者就能夠在 J2EE 應用程式中利用輸入驗證錯誤發起 Buffer overflow 攻擊。

雖然操作或表單可使用其他方法執行驗證，但 Struts Validator 提供了一個很好的方法，來驗證所有的輸入至少接受了最基本的檢查。如不使用此方法，想要建立所有輸入都經過驗證的高層級信任是非常困難、甚至是不可能的。

操作表單對應不應該停用驗證。停用驗證的同時也會停用 Struts Validator，以及由表單執行的所有自訂驗證邏輯。

範例 1：停用驗證的操作表單對應。

<action path="/download"
type="com.website.d2.action.DownloadAction"
name="downloadForm"
scope="request"
input=".download"
validate="false">
</action>

停用驗證會讓此操作暴露在各種攻擊下。未經驗證的輸入是導致各種弱點的根源，如 cross-site scripting、process control 和 SQL injection。雖然 J2EE 應用程式在通常情況下不容易因記憶體損壞攻擊而受到影響，但是如果 J2EE 應用程式連接到未執行陣列界限檢查的本地程式碼，攻擊者就能夠在 J2EE 應用程式中利用輸入驗證錯誤發起 Buffer overflow 攻擊。

當開發人員對 ActionForm 類別進行修改後，很容易忘記去更新驗證邏輯。如果沒有適當的維護驗證邏輯，操作表單和驗證表單之間會出現不一致的現象。

範例 1.a：包含兩個欄位的操作表單。

    public class DateRangeForm extends ValidatorForm {
    String startDate, endDate;
    public void setStartDate(String startDate) {
        this.startDate = startDate;
    }
    public void setEndDate(String endDate) {
        this.endDate = endDate;
    }
}

範例 1.a 顯示了包含 2 個欄位 (startDate 和 endDate) 的操作表單。

範例 1.b：包含三個欄位的驗證表單。

<form name="DateRangeForm">
    <field property="startDate" depends="date">
        <arg0 key="start.date"/>
    </field>
    <field property="endDate" depends="date">
         <arg0 key="end.date"/>
    </field>
    <field property="scale" depends="integer">
         <arg0 key="range.scale"/>
    </field>
</form>

範例 1.b 為操作表單列出了一張驗證表單。驗證表單列出了第三個欄位：scale。第三個欄位的存在表示 DateRangeForm 是在沒有考慮驗證的情況下修正的。

維護驗證邏輯，並與應用程式的其他部分保持同步化是非常重要的。未經檢查的輸入是導致目前最糟糕、最常見的軟體安全問題的根源。Cross-site scripting、SQL injection 和 process control 的弱點是由於缺少輸入驗證或輸入驗證不完整而造成的。雖然 J2EE 應用程式在通常情況下不容易因記憶體損壞攻擊而受到影響，但是如果 J2EE 應用程式連接到未執行陣列界限檢查的本地程式碼，攻擊者就能夠在 J2EE 應用程式中利用輸入驗證錯誤發起 Buffer overflow 攻擊。

ABAP 系統欄位在 ABAP 程式中始終可用。在啟動程式之後、傳送螢幕之後以及變更內部模式之後，執行階段系統會根據上下文填寫它們。然後它們可用於程式中查詢系統狀態。系統欄位是變數，但應一律視為常數且唯讀。變更它們的值可能會導致遺失程式流程所需的重要資訊。在客戶 ABAP 程式中僅需變更其中少數值。


對於與 ABAP 程式就執行階段特定資訊進行通訊的系統欄位，若變更這些欄位的值，可能導致中斷或 ABAP 程式以非預期的方式執行。

當系統資料或除錯資訊透過輸出串流或記錄功能離開程式時，會發生資訊洩漏。

範例 1：以下程式碼會將異常寫入標準錯誤串流：

try {
    ...
} catch (Exception e) {
    e.printStackTrace();
}

視系統配置而定，此資訊可以傾印到主控台、寫入到記錄檔，或是顯示給遠端使用者。例如，使用指令碼機制時，將輸出資訊從「標準錯誤」或「標準輸出」重新導向至檔案或其他程式的過程是不太有意義的。此外，程式執行所在的系統可能會有遠端記錄機制，例如會將記錄傳送至遠端裝置的「syslog」伺服器。在開發期間，您沒有方法可得知從何處會結束顯示此資訊。

在某些情況下，錯誤訊息會為攻擊者提供系統容易受到哪些確切的攻擊類型影響。例如，資料庫錯誤訊息即可揭露應用程式容易受到 SQL injection 攻擊。其他錯誤訊息還可揭露更多關於系統的間接線索。在 Example 1 中，洩漏的資訊可能會暗示有關作業系統類型、系統上安裝的應用程式，以及管理員在配置程式時所花費的努力等資訊。

在行動運算環境中，資訊洩漏也是令人擔心的事情。使用行動平台時，會從多種來源下載，並在相同裝置上一起執行應用程式。在金融應用程式旁執行惡意程式碼的可能性很高，因此應用程式作者需要留意向裝置上執行的其他應用程式傳送的訊息中應包括哪些資訊。

範例 2：以下程式碼會向註冊的所有 Android 接收者廣播所捕捉異常的堆疊追蹤。

...
try {
  ...
} catch (Exception e) {
    String exception = Log.getStackTraceString(e);
    Intent i = new Intent();
    i.setAction("SEND_EXCEPTION");
    i.putExtra("exception", exception);
    view.getContext().sendBroadcast(i);
}
...

以下是行動環境中特有的另一種狀況。現在，多數行動裝置執行近距離無線通訊 (NFC) 通訊協定，以使用無線電通訊在裝置之間快速共用資訊。裝置距離極為接近或彼此接觸時，才會實現此通訊。即使將 NFC 的通訊範圍限制在幾公分距離，也可能發生竊聽、資料修改及其他多種類型的攻擊，因為 NFC 本身並不能確保安全通訊。

範例 3：Android 平台提供對 NFC 的支援。以下程式碼建立進入範圍內其他裝置的訊息。

...
public static final String TAG = "NfcActivity";
private static final String DATA_SPLITTER = "__:DATA:__";
private static final String MIME_TYPE = "application/my.applications.mimetype";
...
TelephonyManager tm = (TelephonyManager)Context.getSystemService(Context.TELEPHONY_SERVICE);
String VERSION = tm.getDeviceSoftwareVersion();
...
NfcAdapter nfcAdapter = NfcAdapter.getDefaultAdapter(this);
if (nfcAdapter == null)
  return;

String text = TAG + DATA_SPLITTER + VERSION;
NdefRecord record = new NdefRecord(NdefRecord.TNF_MIME_MEDIA,
            MIME_TYPE.getBytes(), new byte[0], text.getBytes());
NdefRecord[] records = { record };
NdefMessage msg = new NdefMessage(records);
nfcAdapter.setNdefPushMessage(msg, this);
...

NFC 資料交換格式 (NDEF) 訊息包含輸入的資料、URI 或自訂應用程式裝載。若訊息包含應用程式的相關資訊 (例如其名稱、MIME 類型或裝置軟體版本)，則可能會向竊聽者洩漏此資訊。

當系統資料或除錯資訊透過輸出串流或記錄功能離開程式時，會發生資訊洩漏。



若設為 true,axis.enableListQuery 會啟用 Web 服務部署描述符號 (WSDD) 的清單。此功能會暴露目前系統組態，而其中可能包含管理服務密碼等敏感資訊。