API 就像是呼叫者與被呼叫者之間簽訂的規定。最常見的 API 濫用形式是由呼叫者這一當事方未能遵守此規定所造成的。例如，如果程式在呼叫 chroot() 後無法呼叫 chdir()，即違反規範如何以安全方式變更使用中根目錄的規定。程式庫濫用的另一個好例子是期待被呼叫者向呼叫者傳回值得信賴的 DNS 資訊。在這種情況下，呼叫者是透過對其行為做出某些假設 (傳回值可用於驗證目的) 來濫用被呼叫者 API。另一方也可能違反呼叫者與被呼叫者間的規定。例如，如果編碼器衍生出子類別 SecureRandom 並傳回一個非隨機值，則違反了規定。
root 權限來執行程式，已經造成了無數的 Unix 安全災難。仔細的檢查您的程式授予的權限是否會引起安全問題是十分重要的，而把那些被授予權限的程式及時撤銷權限也是同等重要，才能把那些弱點引起的破壞控制到最小。root 使用者轉換為另外一個時，這種差異會尤其明顯。 root 權限執行，當訊號發生或執行子處理時，該訊號處理常式或者子處理將會以 Root 權限執行。這樣攻擊者將有可能利用這一點來擴大弱點造成的破壞。root 權限來執行程式，已經造成了無數的 Unix 安全災難。仔細檢閱程式授予的權限是否會引起安全問題十分重要，而把那些被授予權限的程式及時撤銷權限也是同等重要，才能把那些弱點引起的破壞控制到最小。root 使用者轉換為其他使用者時，這種差異會尤其明顯。root 權限執行，當訊號觸發或執行子程序時，該訊號處理常式或子程序將會以 Root 權限執行。攻擊者有可能利用這一點來擴大弱點造成的破壞。root 權限來執行程式，已經造成了無數的 Unix 安全災難。 仔細地檢查您的程式授予的權限是否會引起安全問題是十分重要的，而把那些被授予權限的程式及時撤銷權限也是同等重要，才能把那些弱點引起的破壞控制到最小。root 使用者轉換為其他使用者時，這種差異會尤其明顯。root 權限執行，當訊號觸發或執行子程序時，該訊號處理常式或子程序將會以 Root 權限執行。 攻擊者將有可能利用這一點來擴大弱點造成的破壞。root 權限來執行程式，已經造成了無數的 Unix 安全災難。仔細的檢查您的程式授予的權限是否會引起安全問題是十分重要的，而把那些被授予權限的程式及時撤銷權限也是同等重要，才能把那些弱點引起的破壞控制到最小。root 使用者轉換為另外一個時，這種差異會尤其明顯。root 權限執行，當訊號發生或執行子處理時，該訊號處理常式或者子處理將會以 Root 權限執行。這樣攻擊者將有可能利用這一點來擴大弱點造成的破壞。...
Device.OpenUri("sms:+12345678910");
...
...
[[CTMessageCenter sharedMessageCenter] sendSMSWithText:@"Hello world!" serviceCenter:nil toAddress:@"+12345678910"];
...
// or
...
[[UIApplication sharedApplication] openURL:[NSURL URLWithString:@"sms:+12345678910"]];
...
// or
...
MFMessageComposeViewController *messageComposerVC = [[MFMessageComposeViewController alloc] init];
[messageComposerVC setMessageComposeDelegate:self];
[messageComposerVC setBody:@"Hello World!"];
[messageComposerVC setRecipients:[NSArray arrayWithObject:@"+12345678910"]];
[self presentViewController:messageComposerVC animated:YES completion:nil];
...
...
UIApplication.sharedApplication().openURL(NSURL(string: "sms:+12345678910"))
...
...
let messageComposeVC = MFMessageComposeViewController()
messageComposeVC.messageComposeDelegate = self
messageComposeVC.body = "Hello World!"
messageComposeVC.recipients = ["+12345678910"]
presentViewController(messageComposeVC, animated: true, completion: nil)
...
MultiByteToWideChar()、WideCharToMultiByte()、UnicodeToBytes() 和 BytesToUnicode() 函數，以在任意多位元組 (通常是 ANSI) 字元字串和 Unicode (寬字元) 字串之間進行轉換。由於這些函數用來指明字串長度的引數單位並不相同 -- 一個用的是位元組，另外一個用的是字元 -- 因此很容易造成誤用。在多位元組字元字串中，每個字元佔用的位元組數是可變的，因此這樣的字串長度等於所有位元組數相加。但是在 Unicode 中，字元有固定的長度，所以字串的長度一般都是根據它們擁有的字元數來決定的。所以，在指名字串長度的引數中弄錯了單位，就會產生 Buffer overflow。
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);
}
unicodeUser 的位元組長度，而不是字元的長度。所以呼叫 MultiByteToWideChar() 可能會因而將最多 (UNLEN+1)*sizeof(WCHAR) 個寬字元或者 (UNLEN+1)*sizeof(WCHAR)*sizeof(WCHAR) 個位元組寫入 unicodeUser 陣列，而僅為此陣列分配了 (UNLEN+1)*sizeof(WCHAR) 個位元組。如果 username 字串包含了多於 UNLEN 的字元，那麼呼叫 MultiByteToWideChar() 將會溢出 unicodeUser 緩衝區。sun.misc.Unsafe 中的函數。此類別中的所有函數本質上使用起來都是不安全的，只能透過反映來存取。sun.misc.Unsafe 類別是用於執行不安全的低階操作，並非設定供開發人員使用。Unsafe 類別只能使用可信任的程式碼來取得，並且通常是透過反映取得，因為它可以用於破壞系統或手動配置堆積記憶體，如果處理不當，就可能會對系統產生有害影響。為了確保不會出現錯誤，仔細檢查和測試與 sun.misc.Unsafe 相關的所有功能十分重要。
String password=request.getParameter("password");
...
DefaultUser user = (DefaultUser) ESAPI.authenticator().createUser(username, password, password);