在 .NET 中，您可以使用 BinaryFormatter 類別將物件轉變為二進位串流，該二進位串流包含物件本身以及還原序列化期間重建物件所需的中繼資料。

使用 BinaryFormatter 類別可能導致不安全的還原序列化情景，攻擊者可以執行任意程式碼，濫用應用程式邏輯，或觸發 denial of service 條件。

使用 BinaryFormatter 類型是危險行為，不建議用於資料處理，因為它不能保證安全。

範例 1：該應用程式透過在 runtimeConfig.json 檔案中，將組態屬性 EnableUnsafeBinaryFormatterSerialization 設為 true，允許使用不安全的 BinaryFormatter。

...
AppContext.SetSwitch("System.Runtime.Serialization.EnableUnsafeBinaryFormatterSerialization", true);
...

透過 AccessibleObject API，程式設計人員可以避開 Java 存取規範提供的存取控制檢查。特別是，程式設計人員可藉此允許回傳的物件避開 Java 存取控制，轉而變更私有欄位的值或呼叫私有方法、行為 (通常這是不允許的)。

在一般的 JSF 應用程式中，會使用 UI 元件指定的轉換器和驗證器來轉換值。轉換和驗證本身會在提交頁面時發生。Fusion 應用程式中可加上書籤的檢視不會導致任何頁面提交，因此預設不會執行任何類似的轉換或驗證。

範例 1：下列組態設定檔案片段顯示了一個可加上書籤的檢視範例，該檢視組態為不執行 paramName URL 參數的任何轉換或驗證。

...
    <bookmark>
        <method>#{paramHandler.handleParams}</method>
        <url-parameter>
            <name>paramName</name>
            <value>#{requestScope.paramName}</value>
        </url-parameter>
    </bookmark>
...

不建議開發人員使用未記錄或隱藏的 API 建置其應用程式。 無法保證 Google 在將來不會移除或變更這些 API，因此應加以避免，採用此類方法或欄位有很高的風險性，可能中斷您對應用程式的使用。

程式碼嘗試在 Camera 物件被解除之後，使用該物件。若在未重新要求 Camera 物件的情況下參照該資源，便會拋出異常，並在未能捕捉異常時造成應用程式當機。

範例 1：以下程式碼使用了切換按鈕以開啟和關閉相機預覽。在使用者點選按鈕後，相機預覽便會停止，並釋放相機資源。但是，如果再次點選按鈕，則會在先前釋放的 Camera 物件上呼叫 startPreview()。

public class ReuseCameraActivity extends Activity {
  private Camera cam;

  ...
  private class CameraButtonListener implements OnClickListener {
      public void onClick(View v) {
          if (toggle) {
              cam.stopPreview();
              cam.release();
          }
          else {
              cam.startPreview();
          }
          toggle = !toggle;
      }
  }
  ...
}

程式碼嘗試在媒體物件被解除之後使用該物件。若在未重新要求媒體物件的情況下參照該資源，便會拋出異常，並在未能捕捉異常時造成應用程式當機。

範例 1：以下程式碼使用暫停按鈕以切換媒體播放。在使用者點選按鈕後，目前的歌曲或視訊便會停止，並釋放相機資源。但是，如果再次點選按鈕，則會在先前釋放的媒體資源上呼叫 start()。

public class ReuseMediaPlayerActivity extends Activity {
  private MediaPlayer mp;

  ...
  private class PauseButtonListener implements OnClickListener {
      public void onClick(View v) {
          if (paused) {
              mp.pause();
              mp.release();
          }
          else {
              mp.start();
          }
          paused = !paused;
      }
  }
  ...
}

程式碼嘗試在 Android SQLite 資料庫處理常式已被解除後使用該處理常式。若在未重新建立資料庫連線的情況下參照該處理常式，便會拋出異常，並在未能捕捉異常時造成應用程式當機。

範例 1：以下程式碼可能來自將使用者值暫時快取於記憶體中的程式，但可以呼叫 flushUpdates() 以將變更交付至磁碟。該方法會在更新寫入資料庫後正確關閉資料庫處理常式。然而，若再次呼叫 flushUpdates()，便會在重新初始化資料庫物件前再次參照該物件。

public class ReuseDBActivity extends Activity {
  private myDBHelper dbHelper;
  private SQLiteDatabase db;

  @Override
  public void onCreate(Bundle state) {
      ...
      db = dbHelper.getWritableDatabase();
      ...
  }
  ...

  private void flushUpdates() {
      db.insert(cached_data);     // flush cached data
      dbHelper.close();
  }
  ...
}

Android Class Loading Hijacking 弱點有以下兩種形式：

- 攻擊者可以變更程式為載入類別而搜尋的目錄名稱，從而指向處於其控制下之某個目錄的路徑：攻擊者明確控制應該從其中搜尋類別的路徑。

- 攻擊者可以篡改載入類別的環境：攻擊者間接控制路徑名稱代表的意義。

在此案例中，我們著重於第一種情況，即攻擊者可以控制為要載入之類別而搜尋的目錄的可能性。在以下情況下，會發生此類型的 Android Class Loading Hijacking 弱點：

1. 資料從不可信賴的來源進入應用程式。



2. 資料用作代表程式庫目錄的整個字串或一部分字串，以便搜尋要載入的類別。



3. 藉由從程式庫路徑執行程式碼，應用程式會給予攻擊者不應該擁有的權限或能力。

範例 1：以下程式碼使用使用者可變更的 userClassPath 來決定搜尋要載入的類別所在的目錄。

...
  productCategory = this.getIntent().getExtras().getString("userClassPath");
  DexClassLoader dexClassLoader = new DexClassLoader(productCategory, optimizedDexOutputPath.getAbsolutePath(), null, getClassLoader());
  ...

此程式碼能夠透過修改 userClassPath 的結果來指向所控制的其他路徑，從而讓攻擊者利用應用程式的提升權限，載入程式庫並潛在地執行任意程式碼。因為程式不會驗證從環境讀取的值，所以如果攻擊者可以控制 userClassPath 的值，則攻擊者便可使用與原始應用程式相同的權限，愚弄應用程式，讓應用程式指向他們所控制的目錄，從而載入他們所定義的類別。

範例 2：以下程式碼使用使用者可變更的 userOutput 來決定應寫入最佳化 DEX 檔案的目錄。

...
  productCategory = this.getIntent().getExtras().getString("userOutput");
  DexClassLoader dexClassLoader = new DexClassLoader(sanitizedPath, productCategory, null, getClassLoader());
...

此程式碼可讓攻擊者指定最佳化 DEX 檔案 (ODEX) 的輸出目錄。然後，此程式碼還會讓惡意使用者將 userOutput 值變更為他們所控制的目錄，如外部儲存裝置。一旦完成竄改，便只需將輸出的 ODEX 檔案替換為惡意 ODEX 檔案，就可以使用與原始應用程式相同的權限執行該動作。

當惡意動作執行者可以在指定 Zip 檔案中指定 Zip 檔案項目名稱時，就會出現 Zip Path Traversal 弱點。當惡意指定 Zip 檔案項目名稱時，攻擊者可以在擴充對應的 Zip 檔案時覆寫關鍵系統檔案的內容。攻擊者可能會使用此類路徑穿越習慣用法 (例如 ../ 和 /) 來存取不在程式範圍內的系統檔案。依預設，瞄準 Android 14 及更高版本的 Android 應用程式可能會在 Zip 檔案解壓縮過程中偵測到 ../ 和 / 等習慣用法時法時拋出異常。此安全功能可以被覆寫或完全停用。

範例 1：以下程式碼將停用 Zip Entry Overwrite Protection。

...
dalvik.system.ZipPathValidator.clearCallback();
...

藉由縮小檔案大小進行精簡，可提升應用程式中有 JavaScript 檔案頁面的讀取時間。精簡表示移除非必要內容的程序，這些內容包括空白字元、註解、分號、括號、縮短本機變數的名稱及移除無法取得的程式碼。

範例 1：下列 ASPX 程式碼包含 Microsoft jQuery 程式庫的未精簡版本：

...
<script src="http://applicationserver.application.com/lib/jquery/jquery-1.4.2.js" type="text/javascript"></script>
...

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

若要防止此類攻擊：
1. 使用驗證屬性將針對參數或模型繫結物件參數之成員執行的驗證檢查，以程式化方式註解至 ASP.NET Web API 服務動作。
2. 使用 ModelState.IsValid 檢查模型是否通過驗證。

Bean 屬性名稱和值在填入任何 bean 之前皆需驗證。Bean 填寫功能允許開發人員設定 bean 屬性或巢狀屬性。攻擊者可利用此功能存取類似於 class.classLoader 的特別 bean 屬性，這些屬性允許攻擊者取代系統屬性，並可能執行任意程式碼。

範例 1：以下程式碼會設定使用者控制的 bean 屬性，但不正常驗證屬性名稱或值：

String prop = request.getParameter('prop');
String value = request.getParameter('value');
HashMap properties = new HashMap();
properties.put(prop, value);
BeanUtils.populate(user, properties);

Buffer overflow 可能是軟體安全性弱點最為人知的一種形式。大部分軟體開發人員都知道什麼是 Buffer overflow 弱點，但傳統和新開發的應用程式仍常遭到 Buffer overflow 攻擊。此問題的部份原因是，發生 Buffer overflow 的方式很多，部分原因是人們常常用不恰當的方式來防範 Buffer overflow。

在典型的 Buffer overflow 攻擊中，攻擊者會將資料傳送到程式，而程式會將其儲存在一個較小的堆疊緩衝區內。結果就是呼叫這個堆疊的資訊超出了它的邊界，其中包括函數的回傳指標。該資料設定了回傳指標的值，當函數回傳時，會將控制傳送到攻擊者資料所包含的惡意程式碼。

這類型的堆疊 Buffer overflow 在一些平台和開發社群中仍然很常見，但卻還有多種其他類型的 Buffer overflow，包括堆積 Buffer overflow 和差一錯誤 (off-by-one-error) 等等。有許多優秀的著作提供了關於堆疊 Buffer overflow 如何攻擊的具體資訊，包括 Building Secure Software[1]、Writing Secure Code[2]和 The Shellcoder's Handbook[3]。

在程式碼層級，會發生 Buffer overflow 弱點通常是因為程式設計師的假設被推翻。許多在 C 和 C++ 的記憶體操作函數不執行範圍檢查，且可以輕易地覆寫所操作的緩衝區已分配的範圍。甚至如 strncpy() 的範圍函數，使用不正確時也會引起弱點。大多數 Buffer overflow 弱點的根本原因，都是緩衝區的處理，加上對資料的大小或組成假設錯誤。

Buffer overflow 弱點通常出現在這樣的程式碼中：

- 依靠外部資料來控制運作方式者。

- 仰賴被強制位於程式碼臨接範圍外的資料特性者。

- 程式碼複雜到程式設計師不能準確預測到其運作方式者。



以下範例顯示了這三種情況。

範例 1.a：接下來的程式碼範例展示了通常由第一種情況導致的簡單 Buffer overflow，即靠外部資料控制運作方式者。程式碼使用 gets() 函數，將一個任意長度的資料讀取到堆疊緩衝區。因為沒有什麼方法可以限制這個函數讀取的資料量，所以使用者輸入的字元數必須少於 BUFSIZE，以確保程式碼的安全性。

	...
	char buf[BUFSIZE];
	gets(buf);
	...

範例 1.b：此範例顯示只要使用 >> 運算子將輸入讀取到 char[] 字串中，即可輕易模仿 C++ 中 gets() 函數不安全的運作方式。

	...
	char buf[BUFSIZE];
	cin >> (buf);
	...

範例 2：雖然這個範例中的程式碼也是依賴於使用者的輸入來控制它的運作方式，但是它會藉由使用邊界記憶體複製函數 memcpy() 增加一個間接的層面。此函數接受目的緩衝區、來源緩衝區，以及要複製的位元組數量。輸入緩衝區由 read() 的範圍呼叫所填滿，但使用者指定 memcpy() 要複製的位元組數量。

	...
char buf[64], in[MAX_SIZE];
printf("Enter buffer contents:\n");
read(0, in, MAX_SIZE-1);
printf("Bytes to copy:\n");
scanf("%d", &bytes);
memcpy(buf, in, bytes);
	...

注意：這個類型的 Buffer overflow 弱點 (程式讀取資料，然後信賴其他資料上後續記憶體操作中的一個數值) 在圖形、音頻和其他的檔案處理庫中發生次數頻繁。

範例 3：這是第二種情況的範例，其中的程式碼根據非本地驗證的資料特性而異。在這個範例中，一個名為 lccopy() 的函數將一個字串做為引數讀取，然後將這個字串中所有的大寫字母轉化成小寫字母回傳一個堆疊分配的字串副本。這個函數不會對其輸入執行範圍檢查，因為程式預期 str 始終小於 BUFSIZE。如果攻擊者避開對呼叫 lccopy() 的程式碼的測試，或者，如果程式碼有什麼變化，使得關於 str 長度的假設失真，那麼 lccopy() 就會在 strcpy() 超出邊界的呼叫過程中溢位 buf。

char *lccopy(const char *str) {
	char buf[BUFSIZE];
	char *p;

	strcpy(buf, str);
	for (p = buf; *p; p++) {
		if (isupper(*p)) {
			*p = tolower(*p);
		}
	}
	return strdup(buf);
}

範例 4：下列程式碼示範了第三種情況，其中程式碼太過複雜以致無法輕易預測其行為。這段程式碼來自於主流的 libPNG 圖像解碼器，此解碼器廣泛用於多種應用程式。

該程式碼似乎能安全執行界限檢查，因為它檢查了變數長度的大小，之後這會被用來控制 png_crc_read() 複製的資料量。不過，在測試長度之前，程式碼會立即對 png_ptr->mode 執行檢查。檢查失敗時，系統會發出警告，而處理會繼續執行下去。由於 length 會在一個 else if 區塊中進行測試，所以當第一個檢查失敗時，就不會測試 length；且在呼叫 png_crc_read() 期間對其的盲目使用易引發堆疊 Buffer overflow。

雖然這個範例中的程式碼不是我們所見到的當中最複雜的一個，但是它解釋了為什麼執行緩衝區操作的程式碼的複雜度應該減到最低。

if (!(png_ptr->mode & PNG_HAVE_PLTE)) {
	/* Should be an error, but we can cope with it */
png_warning(png_ptr, "Missing PLTE before tRNS");
}
else if (length > (png_uint_32)png_ptr->num_palette) {
png_warning(png_ptr, "Incorrect tRNS chunk length");
png_crc_finish(png_ptr, length);
return;
}
...
png_crc_read(png_ptr, readbuf, (png_size_t)length);

範例 5：此範例同樣證明了第三種情況，程式的複雜性將 Buffer overflow 的問題暴露出來。在此案例中，弱點歸咎於函數某個不明確的介面，而不是程式碼的結構 (就如同前面一個範例中所描述的)。

getUserInfo() 函數採用一個定義為多位元組字元串的使用者名和一個指標來組成使用者資訊的結構，並將使用者資訊填入這個結構。因為 Windows 對使用者名稱的 authentication 是使用統一的字元編碼標準，所以 username 是第一個從多位元組字元串轉換成統一字元編碼標準的字串的參數。函數接著會不正確地以位元組而非字元傳送 unicodeUser 的大小。呼叫 MultiByteToWideChar() 可能會因此而將最多 (UNLEN+1)*sizeof(WCHAR) 個寬字元，或
(UNLEN+1)*sizeof(WCHAR)*sizeof(WCHAR) 個位元組寫入 unicodeUser 陣列，而僅為該陣列分配了 (UNLEN+1)*sizeof(WCHAR) 個位元組。如果 username 字串包含了多於 UNLEN 的字元，那麼呼叫 MultiByteToWideChar() 將會溢出 unicodeUser 緩衝區。

void getUserInfo(char *username, struct _USER_INFO_2 info){
WCHAR unicodeUser[UNLEN+1];
	MultiByteToWideChar(CP_ACP, 0, username, -1,
    	      			unicodeUser, sizeof(unicodeUser));
NetUserGetInfo(NULL, unicodeUser, 2, (LPBYTE *)&info);
}

Buffer overflow 可能是軟體安全性弱點最為人知的一種形式。大部分軟體開發人員都知道什麼是 Buffer overflow 弱點，但傳統和新開發的應用程式仍常遭到 Buffer overflow 攻擊。此問題的部份原因是，發生 Buffer overflow 的方式很多，部分原因是人們常常用不恰當的方式來防範 Buffer overflow。

在典型的 Buffer overflow 攻擊中，攻擊者會將資料傳送到程式，而程式會將其儲存在一個較小的堆疊緩衝區內。結果就是呼叫這個堆疊的資訊超出了它的邊界，其中包括函數的回傳指標。該資料設定了回傳指標的值，當函數回傳時，會將控制傳送到攻擊者資料所包含的惡意程式碼。

這類型的堆疊 Buffer overflow 在一些平台和開發社群中仍然很常見，但卻還有多種其他類型的 Buffer overflow，包括堆積 Buffer overflow 和差一錯誤 (off-by-one-error) 等等。有許多優秀的著作提供了關於堆疊 Buffer overflow 如何攻擊的具體資訊，包括 Building Secure Software[1]、Writing Secure Code[2]和 The Shellcoder's Handbook[3]。

在程式碼層級，會發生 Buffer overflow 弱點通常是因為程式設計師的假設被推翻。C 和 C++ 中的很多記憶體處理函數都沒有執行邊界值檢查，並會輕易地超出操作中緩衝區被配置的邊界值。甚至如 strncpy() 的範圍函數，使用不正確時也會引起弱點。大多數 Buffer overflow 弱點的根本原因，都是緩衝區的處理，加上對資料的大小或組成假設錯誤。

在此案例中，錯誤建構的 Format String 會導致程式寫入分配記憶體邊界以外的位置。

範例 1：以下程式碼溢出 c，因為 double 類型所需的空間大於為 c 所配置的空間。

void formatString(double d) {
    char c;

    scanf("%d", &c)
}

Buffer overflow 可能是軟體安全性弱點最為人知的一種形式。大部分軟體開發人員都知道什麼是 Buffer overflow 弱點，但傳統和新開發的應用程式仍常遭到 Buffer overflow 攻擊。此問題的部份原因是，發生 Buffer overflow 的方式很多，部分原因是人們常常用不恰當的方式來防範 Buffer overflow。

在典型的 Buffer overflow 攻擊中，攻擊者會將資料傳送到程式，而程式會將其儲存在一個較小的堆疊緩衝區內。結果就是呼叫這個堆疊的資訊超出了它的邊界，其中包括函數的回傳指標。該資料設定了回傳指標的值，當函數回傳時，會將控制傳送到攻擊者資料所包含的惡意程式碼。

這類型的堆疊 Buffer overflow 在一些平台和開發社群中仍然很常見，但卻還有多種其他類型的 Buffer overflow，包括堆積 Buffer overflow 和差一錯誤 (off-by-one-error) 等等。有許多優秀的著作提供了關於堆疊 Buffer overflow 如何攻擊的具體資訊，包括 Building Secure Software[1]、Writing Secure Code[2]和 The Shellcoder's Handbook[3]。

在程式碼層級，會發生 Buffer overflow 弱點通常是因為程式設計師的假設被推翻。C 和 C++ 中的很多記憶體處理函數都沒有執行邊界值檢查，並會輕易地超出操作中緩衝區被配置的邊界值。甚至如 strncpy() 的範圍函數，使用不正確時也會引起弱點。大多數 Buffer overflow 弱點的根本原因，都是緩衝區的處理，加上對資料的大小或組成假設錯誤。

在此案例中，錯誤建構的 Format String 會導致程式寫入分配記憶體邊界以外的位置。

範例 1：以下程式碼溢出 buf，因為視 f 的大小而定，Format String 規範 "%d %.1f ... " 會超出配置的記憶體容量。

void formatString(int x, float f) {
   char buf[40];
   sprintf(buf, "%d %.1f ... ", x, f);
}

Buffer overflow 可能是軟體安全性弱點最為人知的一種形式。大部分軟體開發人員都知道什麼是 Buffer overflow 弱點，但傳統和新開發的應用程式仍常遭到 Buffer overflow 攻擊。此問題的部份原因是，發生 Buffer overflow 的方式很多，部分原因是人們常常用不恰當的方式來防範 Buffer overflow。

在典型的 Buffer overflow 攻擊中，攻擊者會將資料傳送到程式，而程式會將其儲存在一個較小的堆疊緩衝區內。結果就是呼叫這個堆疊的資訊超出了它的邊界，其中包括函數的回傳指標。該資料設定了回傳指標的值，當函數回傳時，會將控制傳送到攻擊者資料所包含的惡意程式碼。

這類型的差一錯誤 (off-by-one error) 在一些平台和開發社群中仍然很常見，但卻還有多種其他類型的 Buffer overflow，包括堆疊和堆積 Buffer overflow 等等。有許多優秀的著作提供了關於堆疊 Buffer overflow 如何攻擊的具體資訊，包括 Building Secure Software[1]、Writing Secure Code[2]和 The Shellcoder's Handbook[3]。

在程式碼層級，會發生 Buffer overflow 弱點通常是因為程式設計師的假設被推翻。C 和 C++ 中的很多記憶體處理函數都沒有執行邊界值檢查，並會輕易地超出操作中緩衝區被配置的邊界值。甚至如 strncpy() 的範圍函數，使用不正確時也會引起弱點。大多數 Buffer overflow 弱點的根本原因，都是緩衝區的處理，加上對資料的大小或組成假設錯誤。

範例 1：以下程式碼包含差一錯誤 (off-by-one error) Buffer Overflow，它是在 recv 傳回 sizeof(buf) 位元組讀取允許上限時發生。在此案例中，後續解除參照 buf[nbytes] 將會在配置記憶體邊界以外寫入 null 位元組。

void receive(int socket) {
   char buf[MAX];
   int nbytes = recv(socket, buf, sizeof(buf), 0);
   buf[nbytes] = '\0';
   ...
}

Buffer overflow 可能是軟體安全性弱點最為人知的一種形式。大部分軟體開發人員都知道什麼是 Buffer overflow 弱點，但傳統和新開發的應用程式仍常遭到 Buffer overflow 攻擊。此問題的部份原因是，發生 Buffer overflow 的方式很多，部分原因是人們常常用不恰當的方式來防範 Buffer overflow 。

在典型的 Buffer overflow 攻擊中，攻擊者會將資料傳送到程式，而程式會將其儲存在一個較小的堆疊緩衝區內。結果就是呼叫這個堆疊的資訊超出了它的邊界，其中包括函數的回傳指標。該資料設定了回傳指標的值，當函數回傳時，會將控制傳送到攻擊者資料所包含的惡意程式碼。

這類型的堆疊 Buffer overflow 在一些平台和開發社群中仍然很常見，但卻還有多種其他類型的 Buffer overflow ，包括堆積 Buffer overflow 和差一錯誤 (off-by-one-error) 等等。有許多優秀的著作提供了關於堆疊 Buffer overflow 如何攻擊的具體資訊，包括 Building Secure Software[1]、Writing Secure Code[2]和 The Shellcoder's Handbook[3]。

在程式碼層級，會發生 Buffer overflow 弱點通常是因為程式設計師的假設被推翻。C 和 C++ 中的很多記憶體處理函數都沒有執行邊界值檢查，並會輕易地超出操作中緩衝區被配置的邊界值。甚至如 strncpy() 的範圍函數，使用不正確時也會引起弱點。大多數 Buffer overflow 弱點的根本原因，都是緩衝區的處理，加上對資料的大小或組成假設錯誤。

範例 1：以下程式碼藉由檢查從 getInputLength() 讀取的不信賴值要小於目的緩衝區 output 的大小，來嘗試避免 off-by-one Buffer Overflow 的發生。但由於 len 和 MAX 的比較為有符號比較法，所以若 len 為負數值，當其轉換為 memcpy() 的無符號引數時，就會變成非常大的正數值。

void TypeConvert() {
   char input[MAX];
   char output[MAX];

   fillBuffer(input);
   int len = getInputLength();

   if (len <= MAX) {
      memcpy(output, input, len);
   }
   ...
}

範本引擎可用於透過動態資料轉譯內容。此內容資料一般受使用者控制，由範本格式化以產生網頁、電子郵件等。範本引擎透過使用程式碼建構 (例如條件、循環等) 處理內容資料，可將強大的語言運算式用於範本中以轉譯動態內容。如果攻擊者可控制要轉譯的範本，便能插入運算式來洩漏內容資料，並在瀏覽器中執行惡意程式碼。

範例 1：以下範例顯示如何從 URL 擷取範本並與 AngularJS 搭配使用來轉譯資訊。

function MyController(function($stateParams, $interpolate){
    var ctx = { foo : 'bar' };
    var interpolated = $interpolate($stateParams.expression);
    this.rendered = interpolated(ctx);
    ...
}

在此情況下，$stateParams.expression將會採用可能由使用者控制的資料，並將此評估為與指定內容搭配使用的範本。進而讓惡意使用者能夠在瀏覽器內執行任何所需程式碼，以擷取與執行內容相關的資訊、尋找有關如何建立應用程式的其他資訊或將此轉變為全面的 XSS 攻擊。

對 Boolean 值的運算和對整數值的運算不同，這有可能會導致一個預期外的結果。

從位元組陣列將資料轉換成 String 時，未指定任何資料超出適用的字元集時將會發生什麼情況。這可導致資料遺失，或是當需要二進位資料來確保遵循正確的安全措施時，這可導致安全等級降低。

範例 1：以下程式碼會將資料轉換成字串以建立雜湊。

  ...
  FileInputStream fis = new FileInputStream(myFile);
  byte[] byteArr = byte[BUFSIZE];
  ...
  int count = fis.read(byteArr);
  ...
  String fileString = new String(byteArr);
  String fileSHA256Hex = DigestUtils.sha256Hex(fileString);
  // use fileSHA256Hex to validate file
  ...

假設檔案的大小低於 BUFSIZE，只要 myFile 中的資訊編碼方式與預設字元集相同，這就可以正常運作，但是如果使用的是不同的編碼，或是這是二進位檔案，將會遺失資料。這進而會導致產生的 SHA 雜湊較不可靠，並且可能表示，比較容易造成衝突，尤其是以相同的值 (例如問號) 表示超出預設字元集的任何資料時。