玄関の鍵をかけたはずが、なぜか泥棒が入ってくる？「CSP」で最強の防犯を実装しよう
こんにちは！セキュリティの世界へようこそ。今日は、Web開発の現場で必ずと言っていいほど耳にする「CSP（Content Security Policy）」についてお話しします。
「CSP？なんか難しそう…」と思うかもしれませんが、大丈夫。実はこれ、皆さんの身近にある「家の防犯」と同じ仕組みなんです。一歩ずつ、一緒に紐解いていきましょう。
—
1. Webサイトにおける「泥棒」とは？
私たちが作るWebサイトには、たくさんの「入り口」があります。フォームからデータを受け取ったり、外部のライブラリを読み込んだり。でも、その入り口を悪用して、「本来動いてはいけない怪しいプログラム（スクリプト）」を勝手に実行させようとするのが、サイバー攻撃者、いわゆる「泥棒」たちです。
これが有名なXSS（クロスサイトスクリプティング）という攻撃です。泥棒は、皆さんのサイトに隠れてこっそり侵入し、ユーザーの個人情報を盗んだり、サイトを改ざんしたりします。
2. CSPは「許可証を持った人しか入れない」最強の門番
これまで、私たちは「鍵をかける（入力値をチェックする）」ことばかりに注力してきました。でも、もし鍵が壊されたり、合鍵を作られたりしたらどうでしょう？
そこで登場するのがCSP（Content Security Policy）です。これは、Webサイトの玄関に立つ「超厳格な門番」のようなものです。
この門番は、ブラウザに対して「このサイトでは、どこの誰が作ったスクリプトなら実行していいか」をあらかじめルールとして伝えておきます。ルールにない怪しいスクリプトがやってきても、門番が「お前は名簿に載っていないな！」と、実行をピシャリと拒否してくれるのです。
3. 実践！CSPの基本設定を書いてみよう
CSPは、Webサーバーからブラウザに送る「HTTPレスポンスヘッダー」という信号で設定します。まずは基本形から見てみましょう。
Content-Security-Policy: default-src ‘self’; script-src ‘self’; object-src ‘none’;
この一行には、こんな意味が込められています。
- `default-src ‘self’`: 基本的に、自分のサイト（同じドメイン）にあるものだけを信頼します。
- `script-src ‘self’`: スクリプトも自分のサイトにあるものだけを許可します。外部の怪しいスクリプトは門前払いです。
- `object-src ‘none’`: Flashなどの古いプラグインは一切禁止。もう時代遅れですからね！
4. 悩みの種「インラインスクリプト」をどう安全に扱うか
開発をしていると、HTMLの中に直接 `` と書く「インラインスクリプト」を使いたくなることがありますよね。でも、これを許可すると泥棒がコードを差し込みやすくなってしまいます。
ここで登場するのが「nonce（ナンス）」という仕組みです。
これは「使い捨ての通行証」のようなもの。サーバーがページを表示するたびにランダムな文字列を生成し、タグに付与します。
HTML側の例:
サーバー側（ヘッダー）の例:
Content-Security-Policy: script-src ‘nonce-EDNnf03nceIOfn39fn3e9h3sdf’;
これなら、泥棒がどんなに怪しいコードを送り込んでも、正しい「通行証」を持っていないので、ブラウザは無視してくれます。
5. フレーム攻撃も防ぐ `frame-ancestors`
最近は、自分のサイトを勝手に他のサイトの枠（フレーム）の中に埋め込まれて、偽のボタンを押させる「クリックジャッキング」という攻撃も増えています。これを防ぐにはこの設定が必須です。
Content-Security-Policy: frame-ancestors ‘self’;
「自分のサイトを埋め込んでいいのは、自分自身だけ！」という強い意志を表明します。これで、他人のサイトからこっそり操作される心配はなくなります。
—
最後に：完璧を目指さず、少しずつ育てよう
CSPの設定は、いきなり厳しくするとサイトが動かなくなることがよくあります。まずは `Content-Security-Policy-Report-Only` というヘッダーを使って、「もしこのルールを適用したら、どこがブロックされるかな？」というテストモードから始めるのがプロの常套手段です。
セキュリティは一度やって終わりではなく、日々の積み重ねです。まずは今日から、自分のサイトのHTTPヘッダーを確認するところから始めてみませんか？
皆さんのWebサイトが、今日も安全でありますように！また次のステップでお会いしましょう。
コメント