5月3日、Mo Beigiが「Security Through Obscurity Is NOT Bad」と題した記事を公開した。この記事では、セキュリティ業界で「悪いもの」とされてきた「曖昧さによるセキュリティ」の再評価について詳しく紹介されている。以下に、その内容を紹介する。
「曖昧さによるセキュリティは悪い」という思考停止
記事は、ある開発者がJavaScriptの難読化について質問したフォーラムでのやり取りから始まる。その質問者は、データスクレイピングボットがAPIリクエストをリバースエンジニアリングするのを困難にしたいと相談していた。
すると、あるユーザーが決まり文句のようにこう回答した:
Security through obscurity is bad(曖昧さによるセキュリティは悪い)
このコメントは多くの支持を集めていたが、著者はこの風潮に疑問を呈する。多くのエンジニアが一度聞いたフレーズをオウムのように繰り返しているだけなのではないかと指摘している。
著者は正確にはこう主張する:
- 曖昧さによるセキュリティは悪くない
- 曖昧さ「だけ」によるセキュリティが悪い(Kerckhoffsの原則)
- 追加レイヤーとしての曖昧さによるセキュリティは良い
現実世界での曖昧さの効果

著者は家の鍵を例に説明している。ドアの鍵穴に鍵を挿したままにしておくのは論外だが、玄関マットの下に予備の鍵を隠すことで、攻撃者が諦める可能性が高くなる。完璧なセキュリティは信頼できる友人や家族に鍵を預けることだが、曖昧さは攻撃のコストを上げる追加レイヤーとして機能する。
実例1: WordPressのテーブルプレフィックス
著者の実体験として、2015年のWordPressプラグインの脆弱性事例が紹介されている。デフォルトのwp_usersをwp_8df7b8_usersのようなランダムなプレフィックスに変更していたため、自動化されたPoC(Proof of Concept)スクリプトがTable 'wordpress.wp_users' doesn't existエラーで失敗し、攻撃を免れた。
他のサイトが「null化」されて破壊される中、この単純な曖昧化が実際に被害を防いだのである。
実例2: CS:GOのデバッグシンボル流出
著者がCS:GOコミュニティサーバーを運営していた際の事例も興味深い。通常、Valveはゲームバイナリからデバッグシンボルを取り除いて出荷している。これにより、チート開発者がゲーム内部の関数(例:CBaseEntity::SetHealth)を特定するのが困難になる。
class CBaseEntity {
public:
virtual void SetHealth(int health) = 0;
};
ところが、ValveがmacOS版のアップデートで誤って完全なデバッグシンボル付きのバイナリを配布してしまった。これにより、サーバー運営者は新しいMODを作成できるようになったが、同時にチート開発者も活動を活発化させた。Valveはすぐにミスに気づき、デバッグシンボルを取り除いた版を再リリースした。
実例3: 企業レベルでの難読化
Google reCAPTCHAは重厚で洗練された難読化を使用してボットの自動化を困難にしている。Netflixもブラウザ側のDRMコンポーネントで難読化を使用し、動画の抽出を困難にしている。Riot Gamesも、カーネルレベルのアンチチートシステム「Riot Vanguard」とサーバー間の通信で難読化を使用している。
AIの時代でも曖昧さは有効
「AIの進歩により難読化は無意味になった」という意見に対し、著者は実体験で反論している。
昨年、著者がCTF(Capture The Flag)チャレンジをClaude Opus 4.5に解かせようとしたところ、4.5時間のトークン消費と約300ドルのコストをかけてようやく解決できた。使用したトークンは入力6100万、出力1100万に及んだ。
解決策が存在すると分かっているCTFでさえこの状況なのに、結果が保証されない実際の攻撃で、悪意のある攻撃者が1つの角度に300ドルものコストを払い続けるだろうか?この不確実性こそが、曖昧さがまだ価値を持つ理由だと著者は主張している。
新しいマントラ
著者は「Security through obscurity is bad」という思考停止的なフレーズではなく、以下の2つのステートメントを広めることを提案している:
曖昧さ「だけ」によるセキュリティは悪い
追加レイヤーとしての曖昧さによるセキュリティは良い
曖昧さは適切なセキュリティ対策の追加レイヤーとして、攻撃者のコストと時間を増加させる有効な手段であり続けているのだ。
詳細はSecurity Through Obscurity Is NOT Badを参照していただきたい。