コードレビューの現場で：その`$_GET`、本当にそのまま通すつもりか？
テックリードの私だ。今日のコードレビューも相変わらずだな。
リクエストパラメータの生データをそのままクエリビルダに突っ込むコードが平然と上がってくる。お前らはセキュリティパッチが当たった瞬間に安眠できるほどお人好しなのか？
「ちゃんとバリデーションかけてます」「エスケープしてます」――口頭での言い訳は型チェッカーの前では無意味だ。人間の目なんてものは、深夜3時のデバッグ時にはただの飾り下がりになる。信頼できるのは、コンパイル時に冷徹にコードを切り捨てる型システムだけだ。
HHVMの深淵を覗く我々Hackエンジニアには、ランタイムの気まぐれに頼る必要などない。HackのTaint Analysis（汚染解析）を活用すれば、「未検証のデータ（Taint）」が「危険なシンク（Sink）」に到達する経路を、型チェッカーが静的に完全封鎖してくれる。
今回は、Hackの厳格モード（Strict Mode）と型システムを極限まで利用し、セキュリティインジェクションをコンパイルエラーとしてねじ伏せる実践的アーキテクチャを伝授する。
—
HackのTaint Analysis：静的型システムによる要塞の築き方
動的言語のセキュリティ対策は、往々にして「テスト漏れ」や「リファクタリング時のうっかり」で崩壊する。しかし、HackのTaint Analysisは違う。
汚染されたデータは、型レベルで「感染者」としてマークされる。この感染データを安全な型（Sanitizedな型）に変換する関数――すなわち境界（Boundary）を通過させない限り、型チェッカーは容赦なくビルドを止める。
1. 汚染データと安全なデータの型定義
まずは、未検証の入力値と、サニタイズ済みの値を明確に型レベルで分離する。ここが設計の肝だ。
hh_strict
namespace Security;
// 汚染されたデータを表すマーカー（実際にはPhantom Typeや専用のラップクラスを使う）
class Tainted
public function __chno__(private T $raw) {}
public function getRaw_DANGEROUS(): T {
return $this->raw;
}
}
// サニタイズ済みであることを保証された型
class Sanitized
public function __chno__(private T $safe) {}
public function get(): T {
return $this->safe;
}
}
…と言いたいところだが、Hackの最新の静的解析基盤では、アノテーションとビルトインのフロー解析を組み合わせることで、クラスでラップせずともプリミティブなレベルでデータの追跡が可能だ。実務では、カスタムパーサーや型ガード関数を組み合わせて、型チェッカーに「この関数を通ったデータは安全である」と証明させる。
—
実践：SQLインジェクションをコンパイルエラーにするプロダクションコード
以下のコードを見てほしい。これが、レビューで一発レッドカードを食らう「危険なコード」と、型システムによって守られた「堅牢なコード」の対比だ。
hh_strict
namespace App\Database;
type UserId = int;
// ==========================================
// 危険なアンチパターン（レビュー拒否対象）
// ==========================================
class InsecureUserRepository {
public async function findUserUnsafe(string $rawInput): Awaitable
// 警告: 外部入力をそのままSQLにバインドしている（型で担保されていない）
$sql = “SELECT FROM users WHERE id = ” . $rawInput;
return HH\Asio\join($this->executeSql($sql));
}
private async function executeSql(string $sql): Awaitable
// DB実行モック
return dict[];
}
}
// ==========================================
// 堅牢なプロダクション設計
// ==========================================
// 1. サニタイズ済みの安全な入力を表すラップ型
final class SafeQueryParam {
private function __construct(private int $value) {}
// 唯一の生成経路：ここで厳格なバリデーションを行う
public static function tryCreate(mixed $input): ?this {
if (is_int($input)) {
return new static($input);
}
if (is_string($input) && \preg_match(‘/^\d+$/’, $input)) {
return new static((int)$input);
}
return null;
}
public function getValue(): int {
return $this->value;
}
}
class SecureUserRepository {
// 引数に「生データ」を受け取らせない。必ず SafeQueryParam を強要する。
public async function findUserSecure(SafeQueryParam $param): Awaitable
// ここに到達時点で、$param->getValue() は確実に安全な int であることが保証されている
$id = $param->getValue();
// プリペアドステートメントのプレースホルダー（型安全なクエリビルダー）
$sql = “SELECT FROM users WHERE id = :id”;
return HH\Asio\join($this->executePrepared($sql, shape(‘id’ => $id)));
}
private async function executePrepared(string $sql, shape(…) $params): Awaitable
// 堅牢なDBレイヤーとの通信
return dict[];
}
}
なぜこの設計が優れているのか？
1. 不正な入力を型レベルで排除: `findUserSecure` のシグネチャが `SafeQueryParam` を要求しているため、コントローラー層でバリデーションをサボったコードを書いた瞬間、HHVMの型チェッカー（`hh_client`）がビルドエラーを吐く。
2. 認知負荷のゼロ化: リポジトリ層の開発者は、「この引数は本当にサニタイズされているか？」と疑う必要がない。型が `SafeQueryParam` であれば、100%安全であると数学的に証明されているからだ。
3. リファクタリング耐性: 後から誰かがコードを改変し、バリデーションをバイパスして直接リポジトリを呼び出そうとしても、型不一致によりコンパイルが通らない。テストコードすら書く前に不正なコードを弾き出せる。
—
パフォーマンス上の注意点：型安全とオーバーヘッドのバランス
「こんな厳格なラッパクラスを作ったら、オブジェクト生成のメモリオーバヘッドやGC（ガベージコレクション）の負荷が馬鹿にならないのではないか？」
そう勘繰る鋭いエンジニアもいるだろう。だが、HHVMのアーキテクチャを理解していれば、その懸念が杞憂であることがわかる。
- JITコンパイラの最適化: HHVMのTC（Translation Cache）は、このような小さなファクトリーメソッドやイミュータブルなラッパクラスを強烈にインライン展開する。実行時には、プリミティブな型を直接扱っているのとほぼ同等のパフォーマンスまで最適化される。
- メモリの局所性: `SafeQueryParam` のようなファイナルクラスは、構造化データとしてヒープ上のアロケーションを最小限に抑えるように設計可能だ。
ただし、ホットパス（1秒間に数万回呼ばれる内部ループなど）の内部で過剰にオブジェクトを生成・破棄するのは避けるべきだ。境界（境界領域：HTTPリクエストや外部APIとのI/O）でのみ厳格な型チェックとラッピングを行い、ドメイン層の内部ではプリミティブ型に落とし込む、というレイヤードアーキテクチャを徹底せよ。
—
本日のまとめ：セキュリティは「お祈り」ではなく「コンパイル」で勝ち取れ
セキュリティを「開発者の意識の高さ」に依存しているプロジェクトは、いつか必ず破綻する。深夜の障害対応で疲弊したエンジニアが、うっかりバリデーションをスキップしたコードをマージする未来は容易に想像がつくだろう。
Hackの厳格モードと型システムを使いこなせば、セキュリティホールとなり得るパスを「コンパイルエラー」という最強の防壁で塞ぐことができる。
次のプルリクエストを出す前に、自分の書いたコードの型シグネチャを見直せ。
「外部からの入力が、そのまま危険な処理に流れ込んでいないか？」
型チェッカーがうっとりするような、美しく堅牢なコードを期待している。