従来は人気のあるサービスやアプリケーションだけが攻撃の対象になるものと考えられていた。しかし現在では，少数あるいはまったくユーザのいない新規サービスでさえ，ハッカーの標的とされていることも珍しくない。先日の //Build session で Josh Dunn 氏は，Windows 8 アプリケーションに一般的に見られる脆弱性のいくつかについて説明を行った。
楽観的ミス (Optimistic Mistake) の回避
Windows 8 アプリケーションに多く見られる脆弱性のひとつとして，MSApp.execUnsafeLocalFunction の不適切な利用によるものがある。この関数はアプリケーション内のスクリプトインジェクション検証ルールを無効にするため，結果的にユーザが生成したコンテントを表示する Web サイトと同じ脆弱性に直面することになる。
スクリプトインジェクションは，必要以上に設定されたアプリケーションパーミッションと組み合ったとき，特に始末が悪い。たとえばあるアプリケーションが，ユーザのフォトライブラリへのアクセス権限を持っているものとしよう。ハッカーがスクリプト挿入に成功すれば，そのスクリプトからも同じようにフォトライブラリへのアクセスが可能になるのだ。
当然に思うかも知れないが，eval 関数もアプリケーションに脆弱性をもたらす可能性のある危険な関数のひとつだ。そのため Microsoft では，一般的に eval あるいは名称に "unsafe" と付けられた関数の使用を回避するように推奨している。
JavaScript ライブラリを使用するときには，特に注意が必要だ。ブラウザで使用している限り安全なライブラリでも，Windows 8 で使用する場合には必ずしもそうではない。 Microsoft では，"デフォルト設定が安全" なように特に設計された WinJS の利用を推奨している。今後は徐々に，他のライブラリでもこのような処置が採用されていくものと思われる。
問題を軽減するもうひとつの手段は，アプリケーションの登録機能を制限する，というものだ。アプリケーションには，実際には対応する必要のないシナリオが数多く存在している。例をあげれば，資料を読み込み，あるいは保存する "ドキュメント" 機能をアプリケーションが備える必要はない。ライブラリを経由して，特定のファイル形式の検索ができればそれで十分なはずだ。
これに関連して，不要なファイル拡張子の登録という問題がある。ありがちな誤りは，データをテキストファイルとして保存するアプリケーションを，テキストファイルハンドラとして登録してしまうことだ。これによってアプリケーションが，テキストファイルをオープンするときに起動されるプログラムの一覧に追加されてしまう。ここで重要なのは，テキストファイルを "使う" 機能と "処理する" 機能とを区別することだ。
開発者が誤って設定してしまう機能としては，この他にエンタープライズ認証 (Enterprise Authentication) や共有ユーザー証明書 (Shared User Certificate) などがある。エンタープライズ認証は，ドメインリソースへのアクセスを必要とする内部アプリケーションに限って使用されるべきである。これを使用すればユーザの偽装が可能になるからだ。 共有ユーザ証明書は，ハードウェア証明やスマートカードに使用するためのものだ。
顧客情報の処理責任
顧客から情報を要求する場合，最初から信頼関係を確立しておくことが重要である。収集する情報の内容と理由，収集データがどのようにオプトアウト可能かをユーザに提示することはその一部だ。アプリケーションは可能な限り，個人特定の可能な情報を必要とせずに動作できるようにする必要がある。
個人を特定可能な情報 (PII / Personally Identifiable Information) を扱うときは，必ずセキュアな通信を使用すること。暗号化されない情報の URL への表示は，問題を引き起こすことになる。シリアル番号や IP アドレスといった PII の収集は，可能ならば回避したい。
回避方法のひとつは GetPackageSpecificToken 関数を使用することだ。 このトークンはアプリケーション/ハードウェアの組み合わせ毎にユニークなので，個人情報を使用せずにアプリケーションからデバイスを認識することができる。この方法の欠点は，連携して動作する複数のアプリケーションが，それぞれの所有しているトークンをリンクする手段が必要になることだ。
ユーザ名とパスワードを使用する処理では，それらをローカルファイルやアプリケーション設定の中ではなく，セキュアな資格証明ストア に格納するべきだ。