添加Unicode支持（並非特定於UTF-8）可能帶來的常見內在安全問題來自視覺欺騙的可能性增加，以及歸一化不匹配的問題。

視覺欺騙：說您有每個人都信任的名為“ admin”用戶的論壇。其他人可以註冊一個名為“аdmin”的用戶帳戶（第一個字母為西里爾字母a），並誘使其他人認為自己是站點管理員。這主要是一種用於社交工程的技術：任何軟件都不太可能混淆用戶。 （可以通過讓網站在管理員姓名附近添加特殊格式或風格，使個人資料名稱鏈接到顯示用戶活動歷史記錄和加入日期等個人資料頁面的鏈接來部分解決此特定示例，以便用戶可以通過其他方式來識別其他人除了其可見的可偽造名稱之外，這是一個更普遍的問題，並非unicode支持所獨有：用戶還可以給自己起其他誤導性的名稱，例如“ <site>支持”，“ admin”（帶空格），“ admim”等。）

規範化：某些字符（例如“ö”）可以多種方式表示。它可以是單個字符U + 00F6（帶有DIAERESIS的拉丁文小寫字母O），也可以是兩個字符U + 0061 U + 0308（拉丁文的小寫字母O +組合DIAERESIS）。規範化是將所有文本轉換為組合或分解形式的過程。如果您始終不使用規範化或始終使用規範化，那麼您就不會遇到問題。但是，如果有時這樣做，則可能會遇到安全問題：

例如，OS X標準化文件名中的unicode。假設您有一個網站，沒有在OS X服務器上運行任何與規範化相關的代碼，在該網站上，每當用戶註冊時，都會使用其名稱創建一個文件，並且您使用沒有任何規範化的數據庫來跟踪已經按順序註冊的用戶名以防止名稱被重新註冊。如果您有一個名為“foö”的用戶（使用U + 00F6），則其他人可以註冊一個名為“foö”的帳戶（U + 0061 U + 0308），該站點將允許該帳戶，但會覆蓋由該帳戶創建的文件。第一位“foö”用戶。要解決此問題，您可能需要使應用程序在整個應用程序中保持一致的規範化，或者每當您越過進行規範化不同的某個邊界時（當用戶註冊並需要為其創建文件時，都需要檢查衝突） ，請以獨占模式打開該文件，這樣，如果該文件已經存在，它將失敗，並且您可以阻止新用戶註冊。）

AgentME的答案描述了與Unicode相關的漏洞的兩個重要類別：視覺相似性和規範化。我不會詳細介紹它們。

還有一些與UTF-8特別相關的漏洞。 UTF-8包含一些無效的字節序列，某些應用程序無法很好地處理它們，例如它們可能會崩潰或計算無效的長度。無效的字節序列也可能導致解析器混亂。例如，假設您有將所有單引號加倍以將其填充到SQL查詢中的代碼：

 “ Robert'）; DROP TABLE Studers;-”→“ select * where name =' “ +” Robert“）; DROP TABLE Studers;-” +“'”  

（希望這不是由應用程序代碼完成，而是由低級庫完成……但是在現實世界中，執行此操作的代碼太多，而且並不總是正確。）現在想像在 Robert 之後有一個無效的UTF-8字節序列，例如“ Robert \ 200'）;等等” 。引用庫和數據庫必須同意在這種情況下是否需要將'加倍，並且實際上，它們不一定總是一致，並且您可以進行SQL注入。