許多 DNS 伺服器很容易被攻擊者欺騙，所以您必須設想到您的軟體某一天將會在有問題的 DNS 伺服器環境下執行。如果允許攻擊者進行 DNS 更新 (有時候稱為 DNS 快取下毒)，則他們能夠透過他們的機器制定您網路流量的路徑，或者讓他們的 IP 位址像是在您的領域中。請勿將您系統的安全性依賴於 DNS 名稱上。
範例：以下程式碼範例使用 DNS 尋找來決定進入的要求是否來自可信賴的主機。如果攻擊者可以對 DNS 快取下毒，那麼他們就可以取得信賴。

 IPAddress hostIPAddress = IPAddress.Parse(RemoteIpAddress);
 IPHostEntry hostInfo = Dns.GetHostByAddress(hostIPAddress);
 if (hostInfo.HostName.EndsWith("trustme.com")) {
   trusted = true;
 }

IP 位址比 DNS 名稱可靠，但仍有可能被欺騙。攻擊者可能輕鬆偽造他們所傳送之資料包的來源 IP 位址，但回應資料包將傳回至偽造的 IP 位址。為了查看回應封包，攻擊者需要在受害者的機器和偽造的 IP 位址之間攔截網路資料。為達到所需的攔截，攻擊者一般的做法是嘗試把他們的機器和受害者的機器放在相同的子網路內。攻擊者可藉由使用來源路徑來達到此目的，但現今在大部分的網際網路上已無法使用來源路徑。總而言之，驗證 IP 位址是一種有效的 authentication 方案，但它不是唯一的 authentication 方案。

getlogin() 函數應該傳回包含目前已登入終端機的使用者名稱的字串，但是攻擊者可能讓 getlogin() 傳回登入該機器的任意使用者的名稱。請勿依賴 getlogin() 傳回的名稱來確定是否安全。
範例 1：以下程式碼依賴 getlogin() 來判定是否信任使用者。這很容易被推翻。

 pwd = getpwnam(getlogin());
 if (isTrustedGroup(pwd->pw_gid)) {
 allow();
 } else {
 deny();
 }

不論撰寫程式所使用的語言為何，毀壞性最大的攻擊通常都包含了遠端程式碼的執行，攻擊者可藉此在程式的上下文環境中成功的執行惡意程式碼。在 .NET Framework 中，Decoder 和 Encoding 類別中的 GetChars 方法，以及 Encoder 和 Encoding 類別中的 GetBytes 方法，會在內部針對字元與位元組陣列進行指標算術運算，來將一系列字元轉換為一系列位元組，或是將一系列位元組轉換為一系列字元。
在執行指標算術運算時，開發人員通常會用不適當的方式覆寫上述方法，進而導致執行任意程式碼、濫用應用程式邏輯和 Denial of Service 等弱點。

若作業系統和在其上執行之應用程式之間的字元集不符，則傳送至預設 API 的不支援字元可能最適合對應至危險字元。

範例 1：在 Objective-C 中，下列範例會將含有 UTF-8 字元的 NSString 物件轉換為 ASCII 資料後再轉換回來：

...
unichar ellipsis = 0x2026;
NSString *myString = [NSString stringWithFormat:@"My Test String%C", ellipsis];
NSData *asciiData = [myString dataUsingEncoding:NSASCIIStringEncoding allowLossyConversion:YES];
NSString *asciiString = [[NSString alloc] initWithData:asciiData encoding:NSASCIIStringEncoding];
NSLog(@"Original: %@ (length %d)", myString, [myString length]);
NSLog(@"Best-fit-mapped: %@ (length %d)", asciiString, [asciiString length]);
// output:
// Original: My Test String... (length 15)
// Best-fit-mapped: My Test String... (length 17)
...

如果仔細觀察輸出，「...」字元被會被翻譯成三個連續的句號。如果您比較輸出緩衝區和輸入緩衝區，則您的應用程式可能會面臨 Buffer overflow。其他字元可能對應至一個字元至兩個字元。希臘文的「fi」字元將對應至一個「f」後跟一個「i」。透過使用這些字元來預先載入緩衝區，攻擊者便能完全控制用來讓緩衝區溢出的字元數量。

若作業系統和在其上執行之應用程式之間的字元集不符，則傳送至預設 API 的不支援字元可能最適合對應至危險字元。

範例 1：在 Swift 中，下列範例會將含有 UTF-8 字元的 NSString 物件轉換為 ASCII 資料後再轉換回來：

...
let ellipsis = 0x2026;
let myString = NSString(format:"My Test String %C", ellipsis)
let asciiData = myString.dataUsingEncoding(NSASCIIStringEncoding, allowLossyConversion:true)
let asciiString = NSString(data:asciiData!, encoding:NSASCIIStringEncoding)
NSLog("Original: %@ (length %d)", myString, myString.length)
NSLog("Best-fit-mapped: %@ (length %d)", asciiString!, asciiString!.length)

// output:
// Original: My Test String ... (length 16)
// Best-fit-mapped: My Test String ... (length 18)
...

如果仔細觀察輸出，「...」字元被會被翻譯成三個連續的句號。如果您比較輸出緩衝區和輸入緩衝區，則您的應用程式可能會面臨 Buffer overflow。其他字元可能對應至一個字元至兩個字元。希臘文的「fi」字元將對應至一個「f」後跟一個「i」。透過使用這些字元來預先載入緩衝區，攻擊者便能完全控制用來讓緩衝區溢出的字元數量。

Windows 提供了許多的公用程式函數來操作包含著檔案名稱的緩衝區。在大多數情況下，結果會回傳在做為輸入傳送的緩衝區中。(通常會適當的修改檔案名稱。)大多數函數至少需要 MAX_PATH 位元組長度的緩衝區，但是你應該檢查每一個函數的文件資料。如果緩衝區不夠大，無法儲存操作的結果，就會發生 Buffer overflow。

範例：

char *createOutputDirectory(char *name) {
	char outputDirectoryName[128];
	if (getCurrentDirectory(128, outputDirectoryName) == 0) {
		return null;
	}
	if (!PathAppend(outputDirectoryName, "output")) {
		return null;
	}
	if (!PathAppend(outputDirectoryName, name)) {
		return null;
	}
	if (SHCreateDirectoryEx(NULL, outputDirectoryName, NULL)
        != ERROR_SUCCESS) {
		return null;
	}
	return StrDup(outputDirectoryName);
}

在此範例中，函數在目前目錄中建立了名為「output\<name>」的目錄，並且回傳該名稱的堆積分配副本。對於大多數的目前目錄值和名稱參數，此函數都能夠正常執行。但是如果 name 參數特別長，第二個 PathAppend() 呼叫就可能會溢出 outputDirectoryName 緩衝區，因為這個緩衝區比 MAX_PATH 位元組小。

已知識別的特定函數會盲目的遵循符號連接。發生此狀況時，您的應用程式將會開啟、讀取或寫入資料至符號連接指向的檔案，而非符號連接的代表。攻擊者可能欺騙應用程式寫入其他或重要的系統檔案，或向應用程式提供有問題的資料。

範例 1：以下程式碼會利用遵循符號連結的函數：

...
	struct stat output;
	int ret = stat(aFilePath, &output);
	// error handling omitted for this example
	struct timespec accessTime = output.st_atime;
...

umask() 線上手冊以錯誤指令開頭：

「umask sets the umask to mask & 0777」

儘管這種做法最好遵從 chmod() 的用法，即使用者指定引數中某些位元值來控制檔案存取權限，但事實上 umask() 做的恰恰相反：umask() 將 umask 設為 ~mask & 0777。

umask() 線上手冊接下來描述了對於 umask() 的正確使用方式：

「umask 用來為新建立的檔案設定初始化檔案權限。特別是，umask 的權限關閉了 mode 引數 (例如，一般的 umask 預設值 022 會讓新建立的檔案擁有 0666 & ~022 = 0644 = rw-r--r--的權限，而在一般情況下，mode 應該為 0666)」。

許多 API 都會藉由完全寫入暫存檔案再完全複製該檔案至目標目的地的方式來最小化資料遺失風險。確保識別的方法不會在公開檔案或路徑，或是暫存目錄上運作，因為攻擊者可以在將暫存檔案寫入目標檔案前將其取代。如此可讓攻擊者控制應用程式在公開目錄中使用的檔案內容。

範例 1：以下程式碼會使用易受攻擊的方式將運作中的 transactionId 寫入至應用程式文件目錄中的暫存檔案：

...
//get the documents directory:
let documentsPath = NSSearchPathForDirectoriesInDomains(.DocumentDirectory, .UserDomainMask, true)[0]
//make a file name to write the data to using the documents directory:
let fileName = NSString(format:"%@/tmp_activeTrans.txt", documentsPath)
// write data to the file
let transactionId = "TransactionId=12341234"
transactionId.writeToFile(fileName, atomically:true)
...

不論撰寫程式所使用的語言為何，毀壞性最大的攻擊通常都包含了遠端程式碼的執行，攻擊者可藉此在程式的上下文環境中成功的執行惡意程式碼。若攻擊者能夠上傳檔案至一個可從網路存取的目錄，並將這些檔案傳遞至程式碼解譯器 (例如 JSP/ASPX/PHP)，則他們可能會造成這些檔案內包含的惡意程式碼在伺服器上執行。

下列程式碼收到上傳檔案並將其指派給 posted 物件。FileUpload 屬於 System.Web.UI.HtmlControls.HtmlInputFile 類型。
範例：

HttpPostedFile posted = FileUpload.PostedFile;

即使程式將上傳的檔案儲存於無法從 Web 存取的目錄下，攻擊者仍然可能透過向伺服器環境引入惡意內容中來發動其他攻擊。若程式容易有 Path Manipulation、Command Injection 或 Dangerous File Inclusion 的弱點，則攻擊者可能會上傳含有惡意內容的檔案並利用另一項弱點，使程式讀取或執行該檔。

不論撰寫程式所使用的語言為何，毀壞性最大的攻擊通常都包含了遠端程式碼的執行，攻擊者可藉此在程式的上下文環境中成功的執行惡意程式碼。如果允許攻擊者上傳檔案到可由 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 弱點，則攻擊者可能會上傳包含惡意內容的檔案，並利用另一個弱點使程式讀取或執行該檔案。

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

範例 1：以下程式碼會處理上傳的檔案，並將其移至 Web 根目錄下的目錄中。攻擊者可能將惡意檔案上傳到此程式，然後從伺服器要求這些檔案。

from django.core.files.storage import default_storage
from django.core.files.base import File
...
def handle_upload(request):
  files = request.FILES
  for f in files.values():
    path = default_storage.save('upload/', File(f))
...

即使程式將上傳的檔案儲存於無法從 Web 存取的目錄下，攻擊者仍然可能透過向伺服器環境引入惡意內容中來發動其他攻擊。若程式容易有 Path Manipulation、Command Injection 或 Dangerous File Inclusion 的弱點，則攻擊者可能會上傳含有惡意內容的檔案並利用另一項弱點，使程式讀取或執行該檔。

不論撰寫程式所使用的語言為何，毀壞性最大的攻擊通常都包含了遠端程式碼的執行，攻擊者可藉此在程式的上下文環境中成功的執行惡意程式碼。若攻擊者可以上傳檔案至公開執行的目錄，則他們能在伺服器上執行包含在檔案中的惡意程式碼。

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

不論撰寫程式所使用的語言為何，毀壞性最大的攻擊通常都包含了遠端程式碼的執行，攻擊者可藉此在程式的上下文環境中成功的執行惡意程式碼。若攻擊者能夠上傳檔案至一個可從網路存取的目錄，並將這些檔案傳遞至程式碼解譯器 (例如 JSP/ASPX/PHP)，則他們可能會造成這些檔案內包含的惡意程式碼在伺服器上執行。
即使程式將上傳的檔案儲存於無法從 Web 存取的目錄下，攻擊者仍然可能透過向伺服器環境引入惡意內容中來發動其他攻擊。若程式容易有 Path Manipulation、Command Injection 或 Dangerous File Inclusion 的弱點，則攻擊者可能會上傳含有惡意內容的檔案並利用另一項弱點，使程式讀取或執行該檔。

file 類型的 <input> 標籤表示程式接受檔案上傳。
範例：

<input type="file">