API 操作定義了安全要求，以通知 API 使用者成功叫用這些操作所需的驗證和授權參數。

將安全性設成選用的操作，可能使攻擊者能夠與敏感的 API 端點互動，並允許他們執行應僅限於具有明確權限的特定使用者帳戶的動作。

範例 1：以下 OpenAPI 規格將安全性設成選用，其方法是將一個空白物件 {} 包含到敏感操作的 security 定義中。這會覆寫全域定義的安全要求，並使 createUsers 操作容易遭受未經授權和未經驗證的存取。

{
    "openapi": "3.0.0",
    "info": {
     ...
    },    
    "paths": {
      "/users": {
        "post": {
           "security": [
            {},
            {
              "my_auth": [
                "write:users"
              ]
            }
          ],
          "summary": "Create a user",
          "operationId": "createUsers",
         ...
        }
    ...
    }
}

不安全的驗證方法可能允許攻擊者取得管理權限，並精心安排完整的系統入侵。

將空白字串當做密碼使用是不恰當的。因為它太容易被猜中了。

將密碼以純文字方式儲存於組態設定檔案中，會讓所有能夠讀取此檔案的人都能夠存取被密碼保護的資源。開發人員有時認為他們無法使應用程式防上那些具有組態設定檔案存取權的人的入侵，但這種作法會造成攻擊者的攻擊更加容易。好的 Password Management 原則是不可將密碼以純文字方式儲存。

若啟用 allow_url_fopen 選項，便可使用 HTTP 或 FTP URL 在遠端檔案上執行接受檔案名稱的 PHP 函數。該選項是在 PHP 4.0.4 中增加的，在預設情況下是開啟的，因為它可能會讓攻擊者將惡意內容引入至應用程式中。最理想的情況是，攻擊者改變遠端檔案以引入惡意的內容，因此對遠端檔案進行操作使得應用程式易受攻擊。最差的情況是，攻擊者控制執行應用程式的 URL，則他們可以將 URL 提供至遠端伺服器，將任意的惡意內容插入至應用程式。

範例 1：以下的程式碼會開啟一個檔案並讀取其內容，該檔案名稱由要求參數控制。因為 $file 的值由要求參數控制，所以攻擊者可違反程式設計師的假設，提供 URL 給遠端檔案。

<?php
$file = fopen ($_GET["file"], "r");
if (!$file) {
    // handle errors
}
while (!feof ($file)) {
    $line = fgets ($file, 1024);
    // operate on file content
}
fclose($file);
?>

若啟用 allow_url_include 選項，會導致用於指定在目前頁面包含某個檔案的 PHP 函數 (例如include() 和 require()) 接受指向遠端檔案的 HTTP 或 FTP URL。該選是在 PHP 5.2.0 中增加的，且預設情況下為停用，因為它可能會讓攻擊者將惡意內容引入至應用程式中。最理想的情況是，攻擊者改變遠端檔案以引入惡意的內容，因此包含遠端檔案會使應用程式易受攻擊。最糟糕的情況是，攻擊者控制應用程序用來指定要包含的遠端檔案的 URL，則他們可以將 URL 提供至遠端伺服器，將任意的惡意內容插入至應用程式。

如果將 PHP 解譯器當作 CGI 二位元程式來安裝，則對 PHP 資源的要求通常會被 Web 伺服器重新導向到該解譯器。在此情況下，當使用者要求 http://www.example.com/content/page.php，伺服器會先對/content 目錄執行必要的 access control 檢查，然後再將 access control 重新導向到 PHP 解譯器，同時發出對 http://www.example.com/cgi-bin/php/content/page.php 的要求。

如果停用 cgi.force_redirect (該選項在預設情況下為啟用)，則擁有/cgi-bin/php 存取權的攻擊者可以使用 PHP 解譯器的權限來存取任意的 Web 文件，便可略過任何由伺服器所執行的 access control 檢查。

enable_dl 組態允許動態載入程式庫。這些可能潛在允許攻擊者規避使用 open_basedir 組態設定的限制，並且潛在允許存取系統上的任何檔案。

啟用 enable_dl 可能更便於攻擊者利用其他弱點。

若啟用 file_uploads 選項，會讓 PHP 使用者上傳任意的檔案到伺服器中。允許使用者上傳檔案這個功能本身並不代表一種安全性弱點。不過，這個功能可能導致許多的攻擊行為，因為它提供途徑給惡意的使用者將資料引入伺服器環境。

不論撰寫程式所使用的語言為何，毀壞性最大的攻擊通常都包含了遠端程式碼的執行，攻擊者可藉此在程式的上下文環境中成功的執行惡意程式碼。如果允許攻擊者上傳檔案到可由 Web 存取的目錄上，並將這些檔案傳送至 PHP 解譯器，他們便能使這些檔案中包含的惡意程式碼在伺服器中執行。

範例 1：以下程式碼會處理上傳的檔案，並將其移至 Web 根目錄下的目錄中。攻擊者可能上傳惡意的 PHP 來源檔到此程式中，且稍後從伺服器要求這些檔案，這樣會使 PHP 解譯器執行這些檔案。

<?php
$udir = 'upload/'; // Relative path under Web root
$ufile = $udir . basename($_FILES['userfile']['name']);
if (move_uploaded_file($_FILES['userfile']['tmp_name'], $ufile)) {
    echo "Valid upload received\n";
} else {
    echo "Invalid upload rejected\n";
} ?>

即使程式將上傳的檔案儲存於無法從 Web 存取的目錄下，攻擊者仍然可能透過向伺服器環境引入惡意內容中來發動其他攻擊。如果程式容易出現 path manipulation、command injection 或 remote include 弱點，則攻擊者可能會上傳包含惡意內容的檔案，並利用另一個弱點使程式讀取或執行該檔案。

若啟用 open_basedir 組態選項，該選項會試圖阻止 PHP 程式對 php.ini 中所指定的目錄結構以外的檔案執行操作。如果沒有使用 open_basedir 選項指定任何目錄，則在 PHP 下執行的程式將被授予擁有本地 file system 上所有檔案的完整存取權，這會使攻擊者可讀取、寫入或建立他們原本不該擁有存取權的檔案。

若無法透過 open_basedir 指定限制的目錄集，可能會讓攻擊者更容易發動其他盜取攻擊。

雖然 open_basedir 選項可保證系統的安全性，但其執行方式卻受到 race condition 的不利影響，這可能會讓攻擊者在某些情況下略過該選項所定義的限制[2]。PHP 執行存取權限檢查和開啟檔案間，會存在 time-of-check、time-of-use (TOCTOU) race condition。與其他語言中 file system 的 race condition 相同，此種情況會讓攻擊者將指向透過 access control 檢查的 symlink 替換成另一個原來不能通過測試的檔案，以取得受保護檔案的存取權。

此類攻擊針對的弱點大小視執行存取檢查和開啟檔案間的時間長短而定。即使連續執行呼叫，現今的作業系統也無法保證在處理程序讓出 CPU 之前執行的程式碼數量。攻擊者有許多技術來加長時間長度，使得盜取攻擊更加容易，但即使是很小的時間長度，此攻擊企圖也可以不斷的重複，直到成功為止。

若啟用 safe_mode，safe_mode_exec_dir 選項會限制 PHP 只從指定的目錄執行指令。雖然停用 safe_mode_exec_dir 項目這個作法本身並不是一種安全性弱點，但此新增的方法可能會與其他的弱點一併被攻擊者利用，產生更大的危險。

若存在 open_basedir 配置選項，該選項會試圖阻止 PHP 程式對 php.ini 中所指定的目錄結構以外的檔案執行操作。如果使用 . 指定工作目錄，攻擊者可使用 chdir() 予以變更。

雖然 open_basedir 選項可保證系統的安全性，但其執行方式卻受到 race condition 的不利影響，這可能會讓攻擊者在某些情況下略過該選項所定義的限制[2]。PHP 執行存取權限檢查和開啟檔案間，會存在 time-of-check、time-of-use (TOCTOU) race condition。與其他語言中 file system 的 race condition 相同，此種情況會讓攻擊者將指向透過 access control 檢查的 symlink 替換成另一個原來不能通過測試的檔案，以取得受保護檔案的存取權。

此類攻擊針對的弱點大小視執行存取檢查和開啟檔案間的時間長短而定。即使連續執行呼叫，現今的作業系統也無法保證在處理程序讓出 CPU 之前執行的程式碼數量。攻擊者有許多技術來加長時間長度，使得盜取攻擊更加容易，但即使是很小的時間長度，此攻擊企圖也可以不斷的重複，直到成功為止。

如果啟用 register_globals 選項，會造成 PHP 對所有的 EGPCS (Environment、GET、POST、Cookie 和 Server) 變數進行全域註冊，使得任何使用者在任何 PHP 程式中都可存取這些變數。如果程式設計師在撰寫程式時啟用此選項，或多或少都會導致察覺不到它們所依賴的原始值，這會導致在正常的環境中產生非預期的運作方式，使程式容易遭受惡意環境中的攻擊者攻擊。由於知道 register_globals 所隱含的安全問題，在 PHP 4.2.0 中該選項的預設為關閉，且在 PHP 6 中捨棄且移除該選項。

範例 1：以下程式碼易受 Cross-site scripting 的攻擊。程式設計師假設 $username 的值來自伺服器控制的階段作業，但是攻擊者可能會為 $username 提供惡意值來取代要求參數。如果啟用 register_globals，此程式碼會在其所產生的動態 HTML 內容中包含由攻擊者傳遞的惡意值。

<?php
if (isset($username)) {
    echo "Hello <b>$username</b>";
} else {
    echo "Hello <b>Guest</b><br />";
    echo "Would you like to login?";

}
?>

safe_mode 選項是 PHP 中最重要的 Security Features 之一。若停用 safe_mode，PHP 會以呼叫它的使用者所擁有的權限對檔案進行操作，而使用者通常為具有特定權限的使用者。雖然將 PHP 配置為停用 safe_mode，這個作法本身並不會產生安全性弱點，此無意義的作法可能會與其他的弱點一併被攻擊者利用，產生更大的危險。

若啟用 session.use_trans_sid，會使 PHP 透過 URL 傳送階段作業識別碼，這會使攻擊者更容易劫持目前的階段作業，或是欺騙使用者使用已受攻擊者控制的現有階段作業。

透過 URL 傳送的參數比 POST 參數和 cookie 值較常看見，因為它們常出現於瀏覽器歷史記錄、書籤、記錄檔以及其他高度暴露的位置中。如果攻擊者了解系統中某一作用中階段作業的秘密識別碼，則他們可能將階段作業識別碼傳回到程式中，以劫持使用者的階段作業。

除了 session hijacking 外，在 URL 上暴露階段作業識別碼也會引發 session fixation 攻擊。在一般情況下，攻擊者會利用 Session Fixation 弱點，在 Web 應用程式中建立一個新的階段作業，並記錄關聯的階段作業識別碼。接著，攻擊者會讓受害者使用該階段作業識別碼驗證伺服器，這樣一來，會讓攻擊者透過使用中的階段作業取得存取使用者帳戶的權限。透過 URL 傳送階段作業識別碼可能會讓攻擊者攻擊大批的受害者，這種攻擊方式是藉由將受危害的階段作業識別碼的 URL 透過電子郵件發送給受害者，或另一種大規模的通訊機制來執行。

若啟用 open_basedir 配置選項，該選項會試圖阻止 PHP 程式對 php.ini 中所指定的目錄結構以外的檔案執行操作。雖然 open_basedir 選項可保證系統的安全性，但其執行方式卻受到 race condition 的不利影響，這可能會讓攻擊者在某些情況下略過該選項所定義的限制[2]。PHP 執行存取權限檢查和開啟檔案間，會存在 time-of-check、time-of-use (TOCTOU) race condition。與其他語言中 file system 的 race condition 相同，此弱點會讓攻擊者將指向透過 access control 檢查的 symlink 替換成另一個原來不能通過測試的檔案，以取得受保護檔案的存取權。

此類攻擊針對的弱點大小視執行存取檢查和開啟檔案間的時間長短而定。即使連續執行呼叫，現今的作業系統也無法保證在處理程序讓出 CPU 之前執行的程式碼數量。攻擊者有許多技術來加長時間長度，使得盜取攻擊更加容易，但即使是很小的時間長度，此攻擊企圖也可以不斷的重複，直到成功為止。

相同的 form-bean 名稱並沒有意義，因為相同的名稱在多個 <form-bean> 標籤中使用，只會註冊最後一項項目。

範例 1：以下組態擁有兩個名稱相同的 form-bean 項目。

<form-beans>
  <form-bean name="loginForm" 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-bean name="loginForm" type="org.apache.struts.validator.DynaActionForm">
    <form-property name="favoriteColor" type="java.lang.String" />
  </form-bean>
</form-beans>

Struts 使用 path 屬性來尋找處理要求所需的資源。因為路徑為相對模式的位置，如果路徑不是以「/」字元開頭則視為錯誤。

範例 1：以下組態包含空白路徑。

<global-exceptions>
  <exception key="global.error.invalidLogin" path="" scope="request" type="InvalidLoginException" />
</global-exceptions>

範例 2：以下組態使用不是以「/」字元開頭的路徑。

<global-forwards>
  <forward name="login" path="Login.jsp" />
</global-forwards>

每當已命名動作傳回驗證錯誤[2]時，Struts 規格就會要求 input 屬性。發生驗證錯誤時，input 屬性會指定顯示錯誤訊息的頁面。
範例 1：以下組態定義已命名的驗證作業動作，但並未指定 input 屬性。

<action-mappings>
  <action   path="/Login"
            type="com.LoginAction"
            name="LoginForm"
            scope="request"
            validate="true" />
</action-mappings>

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

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