「セキュリティ対策」という言葉は広く使われますが、実務で押さえておくべきポイントは、実はそれほど多くありません。攻撃の多くは、いくつかの代表的なパターンの組み合わせで説明できます。
この記事では、Webアプリで特に重要な3つの攻撃（SQLインジェクション・XSS・CSRF）と、その土台となる入力・出力の考え方を、全体像として整理します。それぞれの詳しい対策は、個別記事にリンクしています。
Webアプリへの攻撃の多くは、「ユーザーが入力できる場所」を起点にしています。フォーム、URLパラメータ、Cookie、APIのリクエストボディ——どれも、悪意のあるデータが送り込まれる可能性がある入り口です。
つまり対策の基本構造は、次の3点に集約されます。
この3つの言葉の違いについては、 入力バリデーション・サニタイズ・エスケープの違い で詳しく整理しています。
ここからは、実務で特によく問題になる3つの攻撃を、1つずつ見ていきます。
入力値をSQL文に文字列連結で埋め込んでいると、クォートや--を含む文字列によってSQL文の構造そのものを書き換えられてしまいます。対策の基本はプレースホルダ（パラメータ化クエリ）です。
詳しくは SQLインジェクションとは？仕組みと対策 で、実際にSQL文が組み立てられる様子を確認できます。
ユーザー入力をエスケープせずにHTMLへ出力すると、<script>タグなどが実行され、Cookie窃取やページの改ざんにつながります。対策の基本は出力時のエスケープです。
詳しくは XSS（クロスサイトスクリプティング）対策の基本 で、エスケープの有無による違いを確認できます。
ログイン中に別サイトを開いただけで、隠しフォームが自動送信され、意図しない操作が実行されてしまう攻撃です。対策の基本はCSRFトークンとSameSiteCookieです。
詳しくは CSRF対策とは？トークン方式の仕組み で、開いただけで送金が成立してしまう様子を確認できます。
上記3つの攻撃の多くは、そもそも「データを変更する処理をGETで実装している」といった設計ミスが引き金になっているケースも少なくありません。HTTPメソッドの使い分けについては、 GETとPOSTの違いとセキュリティ で解説しています。
ここまでの内容を踏まえて、自分のアプリがどこまで対策できているかを確認してみましょう。チェックが入っていない項目については、対応する解説記事を表示します。
当てはまるものにチェックを入れて「診断する」を押してください。未対策の項目には、対応する解説記事を表示します。
「代表的な脆弱性を網羅的に確認したい」という場合は、OWASP（Open Worldwide Application Security Project）が公開している「OWASP Top 10」が世界的な指標として広く参照されています。ここで紹介したSQLインジェクション・XSS・CSRFに加えて、アクセス制御の不備や、セキュリティ設定の不備なども含めた、より広い分類がまとめられています。自社のアプリを網羅的に点検する際のチェックリストとして活用されることが多い資料です。
Webアプリのセキュリティ対策は、決して際限のない話ではなく、「入力の扱い方」「DBへの渡し方」「画面への出力の仕方」という、いくつかの基本パターンを押さえることでほとんどをカバーできます。
まずは自己診断チェックリストで現状を把握し、抜けている項目から個別記事で対策を確認していくのがおすすめです。