セキュアコーディングとは。開発会社に何を求めればよいか

セキュアコーディングとは、脆弱性を作り込まないようにプログラムを書くことです。よく知られた攻撃の手口に対する書き方の決まりを、開発の全員が守ることが中心になります。発注する側は、「セキュリティに配慮すること」とだけ書くのではなく、参照する基準、確かめ方、見つかった問題の直し方を、要件や契約に具体的に書いておくことが大切です。

セキュアコーディングで防ぐこと

セキュアコーディングで防ぐのは、入力の扱いや権限の確かめ方の誤りから生じる脆弱性です。代表的なものに、データベースへの命令を書き換えられるSQLインジェクションや、ページに不正なスクリプトを埋め込まれるクロスサイト・スクリプティングがあります。

IPAの「安全なウェブサイトの作り方」は、Webサイトの開発者と運営者に向けて、よく知られた脆弱性と対策をまとめた資料です。IPAのページでは、次の脆弱性ごとに解説が設けられています。

• SQLインジェクション
• OSコマンド・インジェクション
• パス名パラメータの未チェック／ディレクトリ・トラバーサル
• セッション管理の不備
• クロスサイト・スクリプティング
• CSRF（クロスサイト・リクエスト・フォージェリ）
• HTTPヘッダ・インジェクション
• メールヘッダ・インジェクション
• クリックジャッキング
• バッファオーバーフロー
• アクセス制御や認可制御の欠落

運用の点検項目をまとめた「安全なウェブサイトの運用管理に向けての20ヶ条」も案内されています。

出典：安全なウェブサイトの作り方（IPA）

用語の短い説明は、用語集のOSコマンドインジェクション、ディレクトリトラバーサル、CSRFにもまとめています。

国際的によく使われる一覧

国際的には、OWASPの「OWASP Top 10」が、Webアプリケーションの主な危険を知るための資料としてよく使われています。2026年11月時点の最新は2025年版（OWASP Top 10:2025）で、次の10項目が挙げられています。

1. Broken Access Control（アクセス制御の不備）
2. Security Misconfiguration（セキュリティの設定の誤り）
3. Software Supply Chain Failures（ソフトウェアのサプライチェーンの失敗）
4. Cryptographic Failures（暗号の不備）
5. Injection（インジェクション）
6. Insecure Design（安全でない設計）
7. Authentication Failures（認証の不備）
8. Software or Data Integrity Failures（ソフトウェアやデータの完全性の不備）
9. Security Logging and Alerting Failures（記録と通知の不備）
10. Mishandling of Exceptional Conditions（例外的な状況の扱いの誤り）

かっこの中の日本語は、当社が内容を短く言い表したものです。書き方の誤りだけでなく、設計、設定、部品の管理、記録までが含まれている点が、セキュアコーディングを書き方だけの問題にしないための手がかりになります。

出典：OWASP Top 10:2025（OWASP Foundation）

開発の各段階で、何をするか

守りは、書く段階だけでなく、要件と設計、実装、テストと診断、運用の各段階に組み込みます。要件と設計の段階では、扱う情報の重さと、誰が何をできるかの権限を決めます。実装の段階では、書き方の決まりを守り、別の人がコードを確かめます。テストと診断の段階では、脆弱性を試し、見つかった問題を直します。運用の段階では、使っている部品に修正版が出たら当てます。

要件と設計

扱う情報（個人情報、取引先の機密など）と、利用者の種類ごとにできる操作を、要件の段階で決めます。OWASP Top 10:2025 に「安全でない設計」が入っているように、作った後では直しにくい弱点は、設計の段階で防ぐことが大切です。ログインの方式、多要素認証の要否、記録する操作も、このときに決めます。

実装とレビュー

開発の会社やチームで、書き方の決まり（入力の扱い、データベースへの命令の組み立て方、出力のときの変換、エラーの表示のしかたなど）を文書にし、全員が同じ決まりで書きます。書いたコードは、書いた人とは別の人がコードレビューで確かめます。ツールでコードを解析して、決まりに反する書き方を見つける方法もあります。

テストと診断

公開する前に、脆弱性を試すテストを行います。重要なシステムや外部に公開するシステムでは、開発した会社とは別の立場からの脆弱性診断を受けることも検討します。診断の頼み方は、脆弱性診断の頼み方と、報告書の読み方で説明しています。診断とペネトレーションテストの使い分けは、ペネトレーションテストと脆弱性診断の違いで説明しています。

運用と部品の更新

公開した後も、使っているフレームワークやライブラリに脆弱性が見つかれば、修正版を当てる必要があります。使っている部品を一覧にしておくと、影響を早く確かめられます。部品の一覧の作り方は、SBOM（ソフトウェアの部品表）とはで扱っています。

発注のときに、要件と契約へ書くこと

発注する側は、セキュアコーディングを要件と契約に具体的に書くことで、開発会社との認識の違いを防げます。書いておきたい項目の例は次のとおりです。

• 参照する基準：IPAの「安全なウェブサイトの作り方」や OWASP Top 10 など、どの基準に沿って開発するか
• レビューのやり方：コードレビューを誰が、どの範囲で行い、記録をどう残すか
• テストと診断：公開の前に脆弱性のテストや診断を行うか、誰が行うか、その費用をどちらが持つか
• 見つかった問題の扱い：検収の前に見つかった問題、検収の後に見つかった問題を、どう直すか
• 部品の扱い：使うオープンソースの部品の一覧を納品物に含めるか、公開した後の更新を誰が担うか
• 記録と納品物：レビューと診断の結果を、納品物として受け取るか

検収の後に見つかった不具合の扱いは、契約不適合責任とは。期間と請求できることで、提案を依頼するときの書き方はRFP（提案依頼書）の書き方：載せる項目と注意点で説明しています。契約の条項の書き方は、弁護士などの専門家にご確認ください。

発注する側が、確かめておきたいこと

開発会社に任せきりにせず、発注する側も、要所で確かめることが大切です。たとえば、開発の途中でレビューの記録を見せてもらう、公開の前の診断の結果と直した内容を受け取る、公開した後の更新の担当と連絡の方法を決めておく、といったことです。

セキュアコーディングは、すべての脆弱性をなくすことを保証するものではありません。作り込みを減らす取り組みと、診断で見つけて直す取り組み、公開した後に更新を続ける取り組みを組み合わせて、危険を下げていくものと考えると整理しやすくなります。Webシステムの守りの全体像は、Webシステムのセキュリティ対策の基本で説明しています。

当社のご支援

アメリア・テクノロジーのWebシステム開発では、要件定義から設計・開発・テスト、公開した後の運用まで受け持ち、その中で守りを組み込みます。他社が開発したシステムについては、セキュリティ診断と対策で、開発した会社とは別の立場から脆弱性を確かめ、直すところまでお手伝いします。当社が開発したシステムの診断は、自己点検として報告します。Webサイトの現状をおおまかに確かめたい場合は、無料のWebサイト診断をお使いください。