Web 開発のセキュリティの基本：OWASP Top 10:2025 と 2026年の注意喚起から、開発者が点検すること

Web 開発のセキュリティの基本は、国内の機関が2026年10月に出した注意喚起と、開発者向けの啓発資料 OWASP Top 10:2025 に書かれていることを、自分のアプリの点検項目に置き換えることです。この記事は、その置き換えの表（点検表）と、同じ回に出す6本の記事への道案内です。

Web アプリを作っている初心者〜若手の人に向けて、機関が何と書いているかを原文に沿って示し、それぞれが6本のどの記事に当たるかを表にしました。各論は6本に任せ、ここでは詳しく書き直しません。6本のどれにも当たらないものは、「この回の記事では扱っていない」と正直に書きます。

日付が効く話には「2026年10月時点」と書いています。2026年10月20日に開いた資料にもとづいていて、新しい資料が出たら、その節を差し替えます。

この記事でわかること

2026年10月時点で、JPCERT/CC・IPA・デジタル庁・個人情報保護委員会が何と書いているか（「相次いで」は誰の言葉か）
JPCERT/CC の4つの型と、個人情報保護委員会の9つの事例を、6本の記事に置き換えた点検表（この記事での振り分け）
OWASP Top 10:2025 の10項目の名前と、6本との対応
IPA「情報セキュリティ10大脅威 2026」の組織向けの順位と、ランサムウェアの扱い
6本に当たらない点検と、自分のアプリで確かめる問い

この記事の使い方：6本の記事は、何の点検？
2026年10月に、国内の機関は何と言っている？（2026年10月時点）
OWASP Top 10:2025 の10項目は、6本のどれに当たる？
IPA「10大脅威 2026」では何が何位？ランサムウェアの扱いは？
1. ランサムウェアは1位。この回では記事にしていない
2. 「サプライチェーン」には2つの意味がある
自分のアプリで、どこから点検する？（点検表）
まとめ
参考資料

この記事の使い方：6本の記事は、何の点検？

同じ回に出す6本は、次のとおりです。自分のアプリに当てはまるものから読んでください。

認証と認可の違いとは？ID を書き換えると他人のデータが見える「IDOR」と API の守り方：ログインや API がある。許されているかの確認（認可）を、サーバーで確かめているか
SQL インジェクションとは？プレースホルダーで防ぐ理由と、DB の権限を絞る方法（SQLite・PostgreSQL）：DB に SQL で問い合わせる。値を文字でつないでいないか
パスワードの正しい受け取り方と保存のしかた：ハッシュ・ソルトと NIST の新しい決まり：自分でログインを作る。平文や速いハッシュで保存していないか
ソフトウェアのサプライチェーン攻撃とは？入口の型と 2026 年の実例（axios・Trivy・TanStack）：npm などの部品や CI を使う。乗っ取りの入口になっていないか
XSS と CSRF の違いとは？React が守ること・守らないこと（React 19 の URL まで）：React などで画面を作る。画面と、サーバーが受ける操作を守れているか
HTTPS と証明書の基本：守られること・守られないことと、有効期間 200 日（2026年3月から）：自分のドメインで公開する。証明書の更新は自動か

用語を2つ補います。JPCERT/CC は、コンピューターセキュリティの情報を集めて注意を呼びかける組織です。OWASP（オワスプ） は、Web アプリのセキュリティを高める活動をしている団体で、OWASP Top 10 は、開発者と Web アプリのセキュリティのための「標準的な啓発資料」と公式が説明している、重大なリスクの10項目です。

2026年10月に、国内の機関は何と言っている？（2026年10月時点）

日付が効く話は、この節にまとめます。この記事では、個別の会社名と事案の件数には触れません。「事故が多い」と言えるのは、各機関が自分の言葉で書いているところまでです。

「相次いで」は、誰の言葉か

JPCERT/CC（JPCERT-AT-2026-0030。2026年10月8日公開・10月9日更新）：「直近2026年9月前後で国内組織における不正アクセスによる個人情報等の漏えい被害が相次いでいます。」
IPA（2026年10月9日）：「不正アクセスの被害による情報漏えい事案の公表が相次いで行われています。」
デジタル大臣（記者会見、2026年10月6日）：「企業や行政機関を標的とした不正アクセスが相次いでおりまして、大量の個人情報が流出する事案が発生をしております。」
個人情報保護委員会（2026年10月7日）：「相次いで」とは書かず、大量の個人データが漏えいした（またはそのおそれがある）漏えい等事案に「接しています」と書いている

「相次いで」を引くときは、どの機関の言葉かを添えます。

JPCERT/CC の注意喚起は、ふだんのランサムウェア攻撃などとは別に、大量の個人情報の漏えいにつながっている攻撃の類型を取り上げるものです。そのうえで、「把握している情報は限定的かつ断片的であるものの」と断り、4つの型は「すべての事案で同一の攻撃手法が使用されていることを示すものではありません」と書いています。IPA も、「特定のプロダクトやサービスの脆弱性を狙った攻撃とは断定されておらず」と書いています。次の表の型は、「9月の事案がこうだった」という答えではなく、寄せられた情報にある手口の例として読みます。

出典: JPCERT/CC 注意喚起・IPA 注意喚起・デジタル大臣記者会見・個人情報保護委員会注意喚起

JPCERT/CC の4つの型を、点検に置き換えると

JPCERT/CC は手口を4つの型（ケース A〜D）に分けています。D は10月9日に追加されました。⚠ この表は、この記事での振り分けです。JPCERT/CC や IPA が「この型にはこの記事」と言っているわけではありません。

型（JPCERT/CC の書き方）	開発者の点検	読む記事
A：さまざまなソフトウェアの既知の脆弱性を探索し攻撃試行するもの（設定ファイルやバックアップファイルの窃取も試みている可能性）	使っているソフトを修正済みの版にする。設定ファイルやバックアップを外から取れる所に置かない	この回の記事では扱っていない
B（a）：公開しているスマートフォンアプリを解析し、API のエンドポイントやキーを特定する	アプリの中に、API の認証に使う秘密鍵や有効期間の長い認証情報を入れない	サーバーで認可を確かめる部分は認証と認可。アプリに秘密を入れない点は、この回の記事では扱っていない（ブラウザーに届く値の話は環境変数と .env の記事）
B（b）：本来画面操作では実行できない内部 API への攻撃（ユーザー権限の変更・不正なアカウントの作成など）	画面の制限に頼らず、API ごと・操作ごとに、サーバーで認可を確かめる	認証と認可
B（b）のうち、NoSQL インジェクションでアカウント情報を特定する	OWASP は NoSQL も SQL と同じインジェクションの仲間と書き、仕組みの考え方はどの種類でも同じとしている	SQL インジェクションは SQL だけを扱う。NoSQL の防ぎ方は、この回の記事では扱っていない
B（c）：他のシステムの侵害で窃取した API キーを使用する	トークンに最小限の権限と有効期限を付け、漏えいが疑われるものを速やかに無効にできるようにする	認証と認可。公開用のトークンが盗まれる話はサプライチェーン攻撃
C：Metabase の SQL インジェクションの脆弱性（CVE-2026-72898）。API への不正なリクエストで悪用される	製品の脆弱性なので、使う側は修正済みの版にする。自分で SQL を組み立てる側は、値をプレースホルダーで渡す	SQL インジェクション
D：公開 Web サーバーからアクセス可能なアプリケーションサーバー上に Web シェル設置（外から命令を送れるようにする仕掛けのこと）	侵入後に広がらないよう、横展開（侵入した先から別のサーバーへ広がること）の対策と、検知・初動を見直す	この回の記事では扱っていない

JPCERT/CC が勧める API 経由のアクセスへの対策は、リクエスト件数の制限（ログインやパスワードリセットなど悪用されやすい機能には個別に）、非公開 API を含む各エンドポイントでのアクセス制御、最小限の権限、トークンの有効期限と、漏えいが疑われるトークンを速やかに無効にできることです。トークンの代表例の仕組みはJWT の記事にあります。

JPCERT/CC のブログ（2026年10月15日）は、攻撃者が AI を利用して既知の脆弱性のスキャンや API 経由の攻撃をしていたと書き、守る側の対策も挙げています。そのうち、外部 URL の内容を取得する API では「アクセス先を制限し、リダイレクト後の宛先も検証する」という SSRF（サーバーに、攻撃者が指定した宛先〔外からは届かない社内のサーバーなどを含む〕へリクエストを送らせる攻撃）の対策は、6本のどれにも当たりません。

また、JPCERT/CC は「BI（ビジネスインテリジェンス）ツールや従業員向け管理システムなど、管理・運用側で不特定多数の利用者からのアクセスを想定していないシステム」も被害に遭っていると書いています。公開するつもりのない管理用の画面や API も、点検の対象に入れます。

出典: JPCERT/CC 注意喚起・JPCERT/CC ブログ（2026年10月15日）・OWASP A05 Injection

個人情報保護委員会の9つの事例を、点検に置き換えると

個人情報保護委員会は、2026年10月7日に注意喚起「大規模な漏えい等事案を踏まえた対応について」を出し、同じページで「WARNING～不正アクセスによる個人データ漏えい防止のための注意喚起～」の改訂版（令和6年12月11日、令和8年10月7日改訂）を出しました。WARNING は、報告を受けた事案を9つの事例に分け、「どれか一つを講じればよいということではなく、多層的に講ずる必要があります」と書いています。⚠ この表も、この記事での振り分けで、委員会が言っているわけではありません。

事例（WARNING の題）	書かれていること	読む記事
１脆弱性が放置された事例	公開された脆弱性と対処方法があるのに放置。VPN 装置などの脆弱性は悪用されることが多い	この回の記事では扱っていない
２脆弱性への対応が遅れた事例	一部の子会社が適時に対応できなかった	この回の記事では扱っていない
３不正ログインの事例	推測されやすい ID・パスワード。複数回の入力ミスでロックしていない。漏えいした ID・パスワードを初期化していない	パスワード（試行回数の制限と多要素認証もその記事）
４グループ会社や海外拠点が狙われた事例	海外拠点の VPN 装置が台帳に載っていなかった	この回の記事では扱っていない
５グループ会社間のアクセス制御不備があった事例	グループ会社間で相互にアクセス可能。管理者パスワードの強度が不十分	この回の記事では扱っていない（管理者パスワードの強さはパスワードに近い）
６個人領域に保存したデータの漏えい事例	個人データを含む電子ファイルを、個人が管理する領域に保存	この回の記事では扱っていない
７グループ会社への監督が不十分な事例	委託元が、委託先の取扱状況を把握する等の監督をしていなかった	この回の記事では扱っていない
８利用するクラウドサービスからの漏えい事例	クラウドサービス提供事業者の業務システムが不正アクセスを受けた	この回の記事では扱っていない
９ APIが悪用される事例	管理から漏れた API。URL や会員 ID のパラメータを書き換えると他ユーザーのデータに届いた。会員 ID が連番で、回数の制限もなかった	認証と認可

事例９の対策例には、点検表の中心になる一文があります。

認証（本人確認）に加え、認可（そのユーザーが当該データにアクセスする権限を有するかの確認）を都度行う仕組みを実装する。

なお、事例３の対策例の「推測されにくい複雑なパスワードを利用するよう従業者を教育する」は、従業者への教育の話です（事例５にも「推測されにくい複雑なパスワードを利用し」とあります）。作る側が利用者のパスワードにどんな規則を課すかとは向きが違うので、そちらはパスワードの記事で NIST SP 800-63B-4 の側から確かめています。

通信の暗号化は、注意喚起の別紙の「手法の例示」にあります（個人データを含む通信の経路または内容の暗号化。例: SSL/TLS）。委員会は、見直しの内容の確定は「来年４月を予定」で、これは見直し予定の内容を先取りして示したものだと書いています。基本はHTTPS と証明書の記事にあります。

出典: 注意喚起の PDF・WARNING の PDF

6本に当たらない点検：IPA とデジタル庁、そして「扱っていないもの」

IPA は「速やかに行うべき点検」として、外部に公開しているアプリの精査（自分で作って動かしているものがあるか、未適用の脆弱性対応パッチはないか）、使っている外部サービスの洗い出し（「作ったはずのないアカウントが存在しないか」）、保有データの再点検（「不要な情報は持たない」）を挙げています。

デジタル大臣が国民に求めた3つ（パスワードの使い回しをやめる・多要素認証・不審なメールや SMS に注意）は、サービスを使う人向けです。作る側は、多要素認証を選べるようにする、漏れたパスワードと照らす、という形で受け止められます。これは、この記事での整理です。

ここまでで「この回の記事では扱っていない」としたものを挙げます。

更新と設定（型 A・事例１・２）：修正済みのアップデートを当てる。例はReact・Next.js の脆弱性の記事。設定の値や秘密の置き方は環境変数と .env の記事
組織の管理（型 D・事例４〜８・取引先や委託先）：侵入後の横展開対策、拠点間のアクセス制御、台帳にない装置、委託先の監督。アプリのコードより、組織の管理の話です
SSRF・フィッシング・ログ：SSRF は外部 URL を取得する API の対策。フィッシングそのものの対策は扱っていない（鍵マークがあってもフィッシングサイトのことがある点はHTTPS と証明書の記事、フィッシングに耐える多要素はパスワードの記事で触れている）。IPA は「ログ取得内容、保持期間の見直し」を挙げている
持たないデータ：IPA の「不要な情報は持たない」、JPCERT/CC の「保存期間を過ぎたデータや利用目的を終えたデータを残さない」、委員会の不要な個人データの消去

まず、自分が作って公開しているアプリ・API・管理画面を、全部言えるか確かめることから始めます。IPA の最初の点検も、ここです。なお、ブラウザから API を呼んだときに出るエラーの直し方は、CORS エラーの記事にあります。

OWASP Top 10:2025 の10項目は、6本のどれに当たる？

OWASP Top 10:2025 は2025年版（8回目）で、公式は Web アプリへの最も重大なリスクについての広い合意を表す資料と説明しています。ここでは、点検の見取り図として使います。公開日は書きません。2025年版では、新しい項目が2つと統合が1つ（SSRF が A01 に）あります。A10 は新しい項目で、A03 は2021年版の A06 を広げたものです。A02 は2021年版の5位から2位になりました。

日本語の名前は、owasp.org の日本語版のページの表記です。右の列は、この記事での振り分けです。

項目	6本との対応
A01 アクセス制御の不備 (Broken Access Control)	認証と認可（ID などのキーを書き換えて認可を回避する問題が入っている）。CSRF も入っているのでXSS と CSRF。SSRF も入っているが、この回の記事では扱っていない
A02 セキュリティ設定の不備 (Security Misconfiguration)	この回の記事では扱っていない
A03 ソフトウェアサプライチェーンの不備 (Software Supply Chain Failures)	サプライチェーン攻撃。2021年版の A06「Vulnerable and Outdated Components」を、依存関係・ビルドの仕組み・配布の基盤の侵害まで広げたもの
A04 暗号化の不備 (Cryptographic Failures)	平文での送信はHTTPS と証明書。salt なしのハッシュや計算量の足りないハッシュはパスワード
A05 インジェクション (Injection)	SQL はSQL インジェクション。XSS はXSS と CSRF。NoSQL などは、この回の記事では扱っていない
A06 安全性を欠いた設計 (Insecure Design)	この回の記事では扱っていない
A07 認証の不備 (Authentication Failures)	パスワード（試行回数の制限・漏れたパスワードの一覧との照合・多要素認証）。認証と認可も関係する
A08 ソフトウェアまたはデータの完全性の不備 (Software or Data Integrity Failures)	この回の記事では扱っていない
A09 セキュリティログとアラートの不備 (Security Logging and Alerting Failures)	この回の記事では扱っていない
A10 例外的な状況への不適切な対応 (Mishandling of Exceptional Conditions)	この回の記事では扱っていない

A05 には、頻度が高く影響が小さいものとして XSS が、頻度が低く影響が大きいものとして SQL インジェクションが入っています（公式の書き方）。前の節の事例９は A01 の側、事例３は A07 の側にあたります（この記事での振り分け）。

出典: OWASP Top 10:2025・日本語版・Introduction・A01・A03・A04・A07・A08

IPA「10大脅威 2026」では何が何位？ランサムウェアの扱いは？

IPA の「情報セキュリティ10大脅威 2026」は、2026年1月29日に公開されました。2025年に社会的影響が大きかったトピックを、約250名の「10大脅威選考会」の投票で決めたものです。組織向けの順位は、次のとおりです。

順位	組織向けの脅威（IPA の表記）
1位	ランサム攻撃による被害
2位	サプライチェーンや委託先を狙った攻撃
3位	AIの利用をめぐるサイバーリスク
4位	システムの脆弱性を悪用した攻撃
5位	機密情報を狙った標的型攻撃
6位	地政学的リスクに起因するサイバー攻撃（情報戦を含む）
7位	内部不正による情報漏えい等
8位	リモートワーク等の環境や仕組みを狙った攻撃
9位	DDoS攻撃（分散型サービス妨害攻撃）
10位	ビジネスメール詐欺

出典: 独立行政法人情報処理推進機構（IPA）「情報セキュリティ10大脅威 2026」（プレス発表・10大脅威 2026 のページ）。脅威名は原文のままです。

1位と2位は2023年以降4年連続で順位が変わらず、3位の AI は初めて候補になって3位に入った、と IPA は書いています。個人向けは順位をつけず、五十音順に10項目を並べています。作る側の仕事に近いのは、「インターネット上のサービスからの個人情報の窃取」と「インターネット上のサービスへの不正ログイン」です。

ランサムウェアは1位。この回では記事にしていない

ランサムウェアとは、データを暗号化して使えなくし、元に戻す代わりに金銭を要求する攻撃です。この回では、ランサムウェアだけを扱う記事は作っていません。

警察庁の「令和7年におけるサイバー空間をめぐる脅威の情勢等について」（令和8年3月）は、令和7年のランサムウェアの被害報告件数は226件で、依然として高水準で推移していると書いています。攻撃の流れの中では「復旧を妨害するため、バックアップも一緒に暗号化される場合が多い」とも書いていて、バックアップも攻撃の対象になりうる、ということです。警察庁は、データを盗んで公開すると脅す二重恐喝が被害の多くを占め、暗号化せずに盗んで脅す手口もあると書いています。同じ報告は、被害組織へのアンケート結果では侵入経路は VPN 機器が6割以上であること、備えとして、ソフトウェア更新・パスワードの適切な管理・アクセス権限等の適切な設定といった基本的な対策の徹底が最も重要だとも書いています。この「基本的な対策」は、この記事の点検表と同じ方向を向いています。

出典: 警察庁の報告（PDF）

「サプライチェーン」には2つの意味がある

IPA の2位は、IPA の解説書によると、取引先や委託先の「ビジネス上の繋がり」と、ライブラリ・ツールなどの「ソフトウェアの繋がり（ソフトウェアサプライチェーン）」を1つにまとめた項目です。10月9日の注意喚起の「取引先や委託先等」は前者の意味です。OWASP の A03 は、ソフトウェアの依存関係・ビルドの仕組み・配布の基盤の話で、後者の側です。サプライチェーン攻撃の記事が扱うのは後者だけで、2位の全部ではありません。委員会の事例８は前者の側です。

出典: IPA 10大脅威 2026 解説書［組織編］（PDF）

自分のアプリで、どこから点検する？（点検表）

ここまでを、自分のアプリに向けた問いにまとめます。並べ方はこの記事での整理で、機関が決めた順序ではありません。 「はい」と言い切れない問いは、右の記事へ進んでください。

問い	開く記事
公開している画面・API・管理画面を、全部言えるか。使っているソフトに未適用の修正はないか。いらないデータを持っていないか	この回の記事では扱っていない（「2026年10月に」の節の「6本に当たらない点検」）
API とデータごとに、「この人に許されているか」をサーバーで確かめているか。ID を書き換えても他人のデータは見えないか	認証と認可
SQL に値を文字でつないでいないか。アプリの DB ユーザーの権限は必要最小限か	SQL インジェクション
パスワードを平文や速いハッシュで保存していないか。受け取る側の決まりは新しい指針と合っているか	パスワード
画面に出す値は文字のまま出ているか。状態を変える操作は、サーバーで守られているか	XSS と CSRF
通信は HTTPS か。証明書の更新は自動になっているか	HTTPS と証明書
使っている部品と、CI・公開用の資格情報が、乗っ取られたときの入口になっていないか	サプライチェーン攻撃。手順はnpm・yarn・pnpmとGitHub Actions

この表はすべてのリスクを覆うものではありません。OWASP の A02・A06・A08・A09・A10、JPCERT/CC の型 A・D、個人情報保護委員会の事例１・２・４〜８、NoSQL インジェクション、SSRF、フィッシングそのものの対策、ランサムウェアは、6本に入っていません。それぞれの公式の文書に当たってください。

この回の 6 本のチェックリストへ

認証と認可の記事：認可の確かめ、ID の扱い、401・403・404 の返し方
SQL インジェクションの記事：プレースホルダー、構造の名前、DB ユーザーの権限
パスワードの記事：保存のしかた、ハッシュ方式と work factor、受け取る側の決まり
サプライチェーン攻撃の記事：lock ファイル、インストール時のスクリプト、GitHub Actions、公開する側
XSS と CSRF の記事：dangerouslySetInnerHTML、URL の確かめ、CSRF の守り、CSP・HttpOnly
HTTPS と証明書の記事：混在コンテンツ、証明書の有効期間と更新、HSTS

まとめ

「事故が多い」と言えるのは、JPCERT/CC・IPA・デジタル大臣が「相次いで」と書いているところまで（2026年10月時点）。個人情報保護委員会は「接しています」と書いている。件数や会社名は出さない
JPCERT/CC の4つの型は、すべての事案で同じ手口が使われたという意味ではない。JPCERT/CC 自身が、把握している情報は限定的かつ断片的だと断っている
型 B（API 経由）と委員会の事例９は認可の確かめに、型 C は SQL インジェクションに、事例３はパスワードとログインに、通信の暗号化は HTTPS に行き着く。この振り分けは、この記事のもの
型 A・D、事例１・２・４〜８、NoSQL インジェクション、SSRF、フィッシングそのものの対策、ランサムウェアは、この回の記事では扱っていない
OWASP Top 10:2025 では、A01・A03・A04・A05・A07 が6本に当たる。IPA 10大脅威 2026 の組織向け1位はランサム攻撃による被害で、警察庁は令和7年の被害報告件数を226件、バックアップも一緒に暗号化される場合が多いと書いている
IPA の2位は「ビジネス上の繋がり」と「ソフトウェアの繋がり」の両方を含み、10月9日の注意喚起は会社どうしの意味、OWASP A03 はソフトウェアの側