見えない文字

U+FEFF - ZERO WIDTH NO-BREAK SPACE

Unicode の U+FEFF には、表示幅ゼロで改行もしない空白文字 ("ZERO WIDTH NO-BREAK SPACE") すなわち何も表示に影響を与えない文字が割り当てられています。
表示に影響を与えないというだけでなく、処理系によってはこの文字の存在自体を無視する場合もありえますし、他の文字コードに変換する際にはこの文字自体がバイト列から削除される可能性もあります。もちろん、そうではなく U+FEFF を独立した1文字とみなす処理系もあります。
つまり、"ABC" U+FEFF "DEF" という文字列と、 "ABCDEF" という文字列を比較したときに、それが等しいと判断されるか、異なった文字列と判断されるかは、処理系によって異なります。文字列の途中に複数の U+FEFF を挟み込むことにより「危険な文字列リスト」との比較を潜り抜けられた後に U+FEFF が削除され、危険な文字列として攻撃に利用されるかも知れません。
また、見えない文字という特質を生かすと、ログファイルを一瞥する限りは不審なユーザによる侵入の痕跡はないのに、実は "gue" U+FEFF "st" という、guest とは異なるアカウントを作成されていた、というようなシナリオも考えられます。これは、皮肉なことにログのビューアがUnicodeに対応すればするほど発見しにくくなります(Unicode非対応であれば、U+FEFFは文字化けした何らかの形で見えることが期待できる)。

U+FEFF のもうひとつの役割 BYTE ORDER MARK

U+FEFF がデータストリームの先頭にあるときには、データストリームのバイト順を決定するための BYTE ORDER MARK として U+FEFF は機能します。
特筆すべきは、UTF-8 においても U+FEFF を挿入することが可能である、という点です。
通常、U+FEFF は BOM としてバイト順を決定するために利用されるので、バイト順が明白な UTF-8 では BOM の存在を忘れがちですが、UTF-8 であっても任意の箇所に BOM(U+FEFF) を挿入することは可能です。
データストリームの先頭というあいまいな点にも注意が必要です。
一部のアプリケーションフレームワークにおいては、提供されるライブラリで Web サーバを作成した場合、(ライブラリの暗黙の機能により) UTF-8 でデータを出力する際に HTTP ヘッダを出力するより「前」に、ストリーム上に BOM を出力することもあるそうです。

(続く)