若啟用 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 透過電子郵件發送給受害者，或另一種大規模的通訊機制來執行。

幾乎每一個對軟體系統嚴重的攻擊都是從破解程式設計師的假設開始的。在攻擊後，程式設計師所建立的假設似乎是脆弱且拙劣的，但在攻擊之前，許多程式設計師會在午休結束之前為他們的假設進行辯護。

在程式碼中很容易發現的兩個可疑假設為：「此方法呼叫永遠都不會失敗」以及「即使此呼叫失敗也沒有關係」。因此當程式設計師忽略情況時，已暗示他們是以其中一個假設來執行操作。

範例 1： 以下所引用的程式碼忽略可能在 CICS 交易時發生的錯誤情況。

...
EXEC CICS
  INGNORE CONDITION ERROR
END-EXEC.
...

如果在此錯誤情況下交易失敗，程式會當作沒有發生任何異常的情況下繼續執行。程式不會記錄有關此特殊情況，這將使得事後嘗試尋找程式此異常的運作方式變得很困難。

幾乎每一個對軟體系統嚴重的攻擊都是從破解程式設計師的假設開始的。在攻擊後，程式設計師所建立的假設似乎是脆弱且拙劣的，但在攻擊之前，許多程式設計師會在午休結束之前為他們的假設進行辯護。

在程式碼中很容易發現的兩個可疑假設為：「此方法呼叫永遠都不會失敗」以及「即使此呼叫失敗也沒有關係」。因此當程式設計師忽略異常時，已暗示他們是以其中一個假設來執行操作。

範例 1：以下所引用的程式碼忽略了由 doExchange() 拋出的罕見異常。

try {
  doExchange();
}
catch (RareException e) {
  // this can never happen
}

如果拋出了 RareException，程式會繼續執行，就像什麼都沒有發生過一樣。程式不會記錄有關此特殊情況，這將使得事後嘗試尋找程式此異常的運作方式變得很困難。

幾乎每一個對軟體系統嚴重的攻擊都是從破解程式設計師的假設開始的。在攻擊後，程式設計師所建立的假設似乎是脆弱且拙劣的，但在攻擊之前，許多程式設計師會在午休結束之前為他們的假設進行辯護。

在程式碼中很容易發現的兩個可疑假設為：「此函數呼叫永遠都不會失敗」以及「即使此呼叫失敗也沒有關係」。因此當程式設計師忽略異常時，已暗示他們是以其中一個假設來執行操作。

範例 1：下列程式碼會忽略執行插入指令時所丟出的數個異常。

PROCEDURE do_it_all
IS
BEGIN
  BEGIN
    INSERT INTO table1 VALUES(...);
    COMMIT;
  EXCEPTION
    WHEN OTHERS THEN NULL;
  END;
END do_it_all;

因為表格不存在、未提供必要值或某些其他原因，就可能會丟出異常。如果發生錯誤，將無法得知訊息，因為程序不會報告該錯誤或記錄發生的錯誤類型。

多重 catch 區塊看上去可能比較繁瑣，但藉由捕捉高層級的類別 (比如 Exception)「濃縮」catch 區塊，可能會混淆那些需要特殊處理的異常，或是捕捉了不應該在程式中某階段捕捉的異常。捕捉範圍過大的異常，實質上是與「Java 分類定義異常」目的相違背的，並且隨著程式的增長且開始拋出新類型的異常時，此做法將導致嚴重的危險。因為，新的異常類型將不會被注意到。

範例 1：以下引用的程式碼使用相同的方式處理三種不同的異常類型。

  try {
    doExchange();
  }
  catch (IOException e) {
    logger.error("doExchange failed", e);
  }
  catch (InvocationTargetException e) {
    logger.error("doExchange failed", e);
  }
  catch (SQLException e) {
    logger.error("doExchange failed", e);
  }

其實，似乎使用單一 catch 區塊來處理這些異常會比較好一點，如下所示：

  try {
    doExchange();
  }
  catch (Exception e) {
    logger.error("doExchange failed", e);
  }

但是，如果修改 doExchange() 後而拋出新的異常類型，而此異常需以不同方式來處理，那麼過大範圍的 catch 區塊將會阻止編譯器指出這個情況 (有新的異常拋出)。此外，新的 catch 區塊也可處理從 RuntimeException 衍生的異常，例如 ClassCastException 和 NullPointerException，而處理這些異常並不在程式設計師的意圖之內。

聲明一個可拋出 Exception 或是 Throwable 異常的方法，會使呼叫者很難處理和修復發生的錯誤。Java 的異常機制被設定為：呼叫者可以很容易的預計到方法有可能會發生什麼錯誤，並且編寫程式碼以處理各個特定的異常情況。同時聲明：一個方法拋出一個過於籠統的異常違反該系統。

範例 1：下列方法拋出三種類型的異常。

public void doExchange()
  throws IOException, InvocationTargetException,
         SQLException {
  ...
}

這樣看起來比較整齊

public void doExchange()
  throws Exception {
  ...
}

這樣做會防礙呼叫者理解和處理所發生異常。此外，如果 doExchange() 方法因為變更了程式碼，而引入一個需要不同處理方式的異常，則不能用簡單的方式來處理該要求。

通常在以下三個情況，程式設計師會擷取 NullPointerException：

1.程式包含了 Null 指標解除參照。擷取異常狀況的結果比修復基本問題還要簡單。

2. 程式明確的拋出了 NullPointerException 異常狀況來提醒出現錯誤情況。

3. 程式碼是測試代碼的一部分，它在測試的類別中提供了非預期的輸入。

在上述三種情況中，只有最後一種是可接受的。

範例 1：以下程式碼錯誤地擷取了 NullPointerException。

  try {
    mysteryMethod();
  }
  catch (NullPointerException npe) {
  }

通常在以下三個情況，程式設計師會擷取 NullReferenceException：

1.程式包含了 Null 指標解除參照。擷取異常狀況的結果比修復基本問題還要簡單。

2. 程式明確的拋出了 NullReferenceException 異常狀況來提醒出現錯誤情況。

3. 程式碼是測試代碼的一部分，它在測試的類別中提供了非預期的輸入。

在上述三種情況中，只有最後一種是可接受的。

範例 1：以下程式碼錯誤地擷取了 NullReferenceException。

  try {
    MysteryMethod();
  }
  catch (NullReferenceException npe) {
  }

finally 區塊中的回傳指令，會導致 try 區塊中所拋出的任意異常遭丟棄。

範例 1：在下列程式碼中，由第二次呼叫 doMagic 方法，同時將 true 參數傳送給該方法，會導致拋出 MagicException 異常，該異常將不會傳送給呼叫者。finally 區塊中的回傳指令，會導致異常遭丟棄。

public class MagicTrick {

public static class MagicException extends Exception { }

public static void main(String[] args) {

  System.out.println("Watch as this magical code makes an " +
                     "exception disappear before your very eyes!");

  System.out.println("First, the kind of exception handling " +
                     "you're used to:");
  try {
    doMagic(false);
  } catch (MagicException e) {
    // An exception will be caught here
    e.printStackTrace();
  }

  System.out.println("Now, the magic:");
  try {
    doMagic(true);
  } catch (MagicException e) {
    // No exception caught here, the finally block ate it
    e.printStackTrace();
  }
  System.out.println("tada!");
}

public static void doMagic(boolean returnFromFinally)
throws MagicException {

  try {
    throw new MagicException();
  }
  finally {
    if (returnFromFinally) {
      return;
    }
  }
}

}

只有在應用程式在非同步結束後需要進行清除動作，才會出現 ThreadDeath 錯誤。如果出現 ThreadDeath 錯誤，請務必重新拋出該錯誤來真正停止執行緒。拋出 ThreadDeath 的用意為停止執行緒。如果接收 ThreadDeath，就會導致執行緒持續執行並造成意外行為，因為原來拋出 ThreadDeath 的使用者想停止該執行緒。

範例 1：下列程式碼捕捉到 ThreadDeath，但並未重新拋出。

try
{
//some code
}
catch(ThreadDeath td)
{
//clean up code
}

在 Java 中，finally 區塊永遠會在對應 try-catch 區塊後執行，而且通常用來釋放已配置資源，例如檔案控制碼或資料庫指標。在 finally 區塊中拋出異常，可以略過重要的清除程式碼，這是因為將中斷正常程式執行。

範例 1：在下列程式碼中，拋出 FileNotFoundException 時，會略過呼叫 stmt.close()。

public void processTransaction(Connection conn) throws FileNotFoundException
{
    FileInputStream fis = null;
    Statement stmt = null;
    try
    {
        stmt = conn.createStatement();
        fis = new FileInputStream("badFile.txt");
        ...
    }
    catch (FileNotFoundException fe)
    {
        log("File not found.");
    }
    catch (SQLException se)
    {
        //handle error
    }
    finally
    {
        if (fis == null)
        {
            throw new FileNotFoundException();
        }

        if (stmt != null)
        {
            try
            {
                stmt.close();
            }
            catch (SQLException e)
            {
                log(e);
            }
        }
    }
}

在以下情況中會出現 Unhandled Exception 弱點：

1. 拋出一個異常

2. 在異常離開目前頁面前，未能對其進行適當處理。

幾乎每一個對軟體系統嚴重的攻擊都是從破解程式設計師的假設開始的。在攻擊後，程式設計師所建立的假設似乎是脆弱且拙劣的，但在攻擊之前，許多程式設計師會在午休結束之前為他們的假設進行辯護。

在程式碼中很容易發現的兩個可疑假設為：「此操作永遠都不會失敗」以及「即使此操作失敗也沒有關係」。因此當程式設計師未擷取到操作可能拋出的異常時，已暗示他們是以其中一個假設來執行操作。

在以下情況中會出現 Unhandled SSL Exception 弱點：

1. 拋出特定 SSL 的異常。

2. 沒有明確地處理異常。

特定 SSL 的異常 javax.net.ssl.SSLHandshakeException、javax.net.ssl.SSLKeyException 和 javax.net.ssl.SSLPeerUnverifiedException 都會傳達與 SSL 連線相關的重要錯誤。如果沒有明確地處理這些錯誤，連線可能會處於一種非預期且潛在不安全的狀態。

幾乎每一個對軟體系統嚴重的攻擊都是從破解程式設計師的假設開始的。在攻擊後，程式設計師所建立的假設似乎是脆弱且拙劣的，但在攻擊之前，許多程式設計師會在午休結束之前為他們的假設進行辯護。

在程式碼中很容易發現的兩個可疑假設為：「此操作永遠都不會失敗」以及「即使此操作失敗也沒有關係」。因此當程式設計師未擷取到操作可能拋出的異常時，已暗示他們是以其中一個假設來執行操作。

在某特定類別中的所有實例中共用一個單一記錄器物件，並且在程式的執行過程中使用同一個記錄器，是個良好的編程方法。

範例 1：接下來的指令錯誤地定義了一個非固定的記錄器。

private final Logger logger =
            Logger.getLogger(MyClass.class);

良好的記錄行為是指為每個類別使用一個記錄器。

範例 1：接下來的程式碼錯誤地聲明 Multiple Loggers。

public class MyClass {
  private final static Logger good =
            Logger.getLogger(MyClass.class);
  private final static Logger bad =
            Logger.getLogger(MyClass.class);
  private final static Logger ugly =
            Logger.getLogger(MyClass.class);
  ...
}

範例 1：程式設計師學習編寫的第一個 Java 程式會如下所示：

public class MyClass
  ...
    System.out.println("hello world");
  ...
}

當大多數的程式設計師繼續學習許多關於 Java 的細微之處時，有一部分人仍僅依賴這些基本知識，總是使用 System.out.println() 來撰寫訊息以執行標準輸出。

問題是，直接在標準輸出或標準錯誤中寫入資訊，通常是用來當做沒有結構的記錄格式。結構化的記錄工具提供了各種功能，如記錄層級、統一的格式化、記錄識別碼、時間戳記，另外可能是最重要的，將記錄訊息引導至正確位置的功能。當系統輸出串流的使用與正確使用記錄功能的程式碼混合在一起，得出的結果通常是一個保存良好但缺少重要資訊的記錄檔。

開發人員廣泛地認同對結構化記錄的需求，但很多人仍然繼續在程式開發前使用系統輸出串流功能。如果您正在檢閱的程式碼已過了程式開發的初始階段，使用 System.out 或 System.err 可能會在轉向結構化記錄系統時產生一個錯誤。