多くの経営者は、事故が起きてから初めてセキュリティを思い出します。管理画面に不正ログインされて価格を書き換えられたり、ユーザーの電話番号が一括で持ち出されたり、公式サイトのトップページに怪しいリンクを貼られたり。後から聞くと、開発者は「機能はすべてテスト済みです」と言います。問題はまさにそこです。機能テストが通ったからといって、セキュリティも問題ないとは限りません。
Webサイト開発におけるセキュリティ脆弱性の多くは、高度な攻撃ではなく、いくつかの基本的な工程が正しく行われていないことに起因します。以下、実際のプロジェクトで最もよくある落とし穴を一つずつ説明します。
一、権限外アクセス：ログインしているからといって何でも見られるわけではない
これは企業サイトや管理システムで最もよくある問題です。ユーザーAがログイン後、アドレスバーの注文IDを1001から1002に変更するだけで、ユーザーBの注文が見えてしまいます。開発者はフロントエンドでボタンを隠すだけで、バックエンドのAPIで「このデータが本人のものかどうか」を検証していないことがよくあります。
対策は簡単です。すべてのAPIで、現在のログインユーザーがそのデータを操作する権限を持っているかを検証する必要があり、「ログインしているかどうか」だけを判断してはいけません。ロール権限も明確に分けるべきで、一般社員と経理が見られるメニューや呼び出せるAPIは必ず異なるようにします。
注意点：権限判定をフロントエンドに書かないでください。フロントエンドのコードはユーザーが変更できます。バックエンドこそが最後の砦です。リリース前に、開発者にIDが関わるすべてのAPIをリストアップさせ、帰属チェックを一つずつ確認させましょう。
二、インジェクション系脆弱性：文字列連結は遅かれ早かれ事故になる
SQLインジェクションは古くからある問題ですが、今でも発生しています。典型的なシナリオは検索ボックスやフィルター条件で、開発者がユーザー入力をそのままSQL文に連結してしまい、攻撃者が特殊な文字列を入力することで条件を回避し、テーブル全体を持ち出されてしまいます。
正しい方法は、すべてパラメータ化クエリまたはORMのバインドパラメータを使用することで、手動で連結してはいけません。コマンド実行やテンプレートインジェクションも同様で、ユーザー入力をコードとして実行する箇所では、必ずホワイトリスト検証を行います。
注意点：コード内にSQLの文字列連結が出現したら、基本的にそのまま差し戻して構いません。また、データベースアカウントにrootを使わず、業務に必要な権限だけを付与すれば、事故が起きた際の被害を半分に抑えられます。
三、ファイルアップロードとダウンロード：最も見落とされやすい入口
企業サイトでは製品画像や契約書の添付ファイルをアップロードし、ミニアプリ開発ではアバターや証明写真をアップロードします。アップロードAPIが拡張子だけを検証している場合、攻撃者はスクリプトを.jpgに改名するだけでアップロードでき、さらにそれを実行させる方法を模索します。
対策：ファイルタイプの検証は拡張子ではなく実際の内容で判断し、アップロードディレクトリではスクリプトの実行を禁止し、ファイル名を変更して保存する。ダウンロードAPIも同様に権限を検証し、パスを変更するだけでサーバー上の設定ファイルをダウンロードされないようにします。
注意点：アップロードディレクトリとWebサイトのプログラムディレクトリは分離してください。多くの事故は、画像とコードが同じ実行可能ディレクトリに置かれていることが原因です。
四、API認証と機密情報の露出
App開発やミニアプリ開発では、APIが主な攻撃対象面となります。よくある問題は三つあります。APIにレート制限がなく、認証コードを無限に試行できる。返却データに不要なフィールドまで含めてしまい、例えばユーザーリストに身分証番号が含まれる。エラーメッセージが詳細すぎて、データベースのエラーをそのままフロントエンドに返してしまう。
対策：ログイン、SMS、決済系のAPIには必ずレート制限とリプレイ防止を実装し、返却フィールドは必要に応じて削減し、エラーメッセージを統一する。ログにパスワードや完全な電話番号を平文で記録しないでください。
注意点：テスト環境のデータを本番環境にそのまま同期しないでください。多くの情報漏洩は、テストDBに実ユーザーデータが入っており、テスト環境の防御がほぼゼロであることが原因です。
五、リリースは終点ではない：セキュリティテストをプロセスに組み込む
多くのチームはセキュリティを一度きりのチェックと捉え、リリース後は誰も管理しません。実際には、新機能のリリース、依存関係のアップグレード、サーバー設定の変更などによって、問題が再び持ち込まれる可能性があります。
セキュリティテストをリリースフローに組み込むことをお勧めします。毎回の大きな改版時にAPIと権限の再チェックを行い、定期的に依存関係の脆弱性をスキャンし、重要なシステムでは年に一度ペネトレーションテストを実施します。公式サイトのリニューアルのようなプロジェクトでは、ページ改修後にフォーム、検索、管理画面ログインを一通り確認するだけで、コストは低く、ほとんどの初歩的な問題を防げます。
注意点：スキャンレポートの件数だけを見ないでください。ツールが検出した高危険度の項目は、実際に悪用可能かどうかを人手で確認する必要があります。誤検知も見逃しもよくあるため、最終的にはビジネスロジックの脆弱性を人の判断で見極める必要があります。
MIC Studio に依頼するのが適しているケース
チームに専任のセキュリティ担当者がいない場合、または公式サイトのリニューアル、予約ミニアプリ、管理システムの開発を予定していて、リリース後に後手で対応したくない場合は、セキュリティ部分を外部に任せることができます。
MIC Studio は企業サイト、ミニアプリ開発、App開発のほか、スクリプト開発やWebサイトセキュリティテスト、リバースエンジニアリングテストも手がけています。私たちは事故が起きてから補うのではなく、開発段階で権限、アップロード、APIといった問題をチェックリストに沿って一通り確認することを習慣としています。
実行可能な三つの提案
1. リリース前にAPIリストを作成し、ログイン検証、データ帰属検証、レート制限の三点が整っているかを一つずつ確認し、欠けている項目があればTODOとして記録する。
2. アップロードとダウンロードを個別のリスクポイントとしてレビューし、ストレージディレクトリが実行不可であること、ファイルタイプを内容で判断していること、ダウンロードが権限検証を経由していることを確認する。
3. セキュリティテストに予算と時間を確保し、重要なバージョンのリリース前に一連のチェックを行い、セキュリティをリリース後のオプション扱いにしない。