個人開発のセキュリティを最初の一歩から固める

セキュリティ対策と聞くと、専門家だけの高度な世界に思えます。しかし実際に個人開発で起きる事故の多くは、少数の定番パターンです。定番を知り、最初から避ける形で作れば、対策の大半は追加作業なしで済みます。

この記事では、OWASP Top 10とMDNのWebサイトセキュリティの一次情報から、個人開発者が最初に押さえるべき考え方を選んで整理します。

攻撃は「自分のサイトが狙われるか」ではない

「小さな個人サイトを誰が攻撃するのか」と思うかもしれません。実際の攻撃の多くは人が選んで行うのではなく、プログラムがインターネット全体を機械的に走査しています。公開した瞬間から、規模に関係なく、既知の弱点を探すアクセスは届きます。

だからこそ、狙われにくくするのではなく、定番の弱点を最初から作らないことが個人開発の現実的な防御になります。

利用者の入力をそのまま信用しない

Webセキュリティの原則を一つだけ選ぶなら、「利用者から届くデータをそのまま信用しない」です。フォームの入力、URLのパラメータ、アップロードされたファイルは、すべて想定外の内容が届く可能性があります。

入力は種類・長さ・形式を確認してから使います（数値のはずの欄に文字列が来る、などを想定します）
入力をデータベースへの命令文に直接つなげない。ライブラリが用意する安全な受け渡し方法（プレースホルダー）を使います
入力を画面へ表示するときは、フレームワークの標準の表示方法を使い、生のままページへ埋め込みません

多くのフレームワークは安全な書き方が標準になっています。危ないのは、標準を迂回する特別な書き方をAIや古い記事からコピーしたときです。見慣れない書き方が出てきたら、AIが書いたコードを自分で確かめるの手順で、なぜその書き方なのかを確認します。

ログインまわりは自作しない

認証はセキュリティ事故が最も集中する領域です。個人開発では次の方針が安全です。

パスワードの保存や照合を自作せず、フレームワークの認証機能か外部の認証サービスを使います
「ログインしているか」だけでなく「その操作をしてよい人か」を、データを返す直前に確認します（他人のIDをURLに入れたら他人のデータが見える、が定番の事故です）
パスワードリセットなど、メールで本人確認する導線は、リンクの有効期限と一回限りの利用を確認します

通信と設定の基本を確認する

作り方だけでなく、公開時の設定にも定番があります。

サイト全体をHTTPSで配信します（多くのホスティングサービスでは標準で有効です）
管理画面やテスト用ページを、URLを知らなければ大丈夫という状態で放置しません
エラー画面に内部の情報（スタックトレースや設定値）を表示しない設定になっているか確認します
APIキーなどの秘密情報の扱いは個人開発の秘密情報を安全に管理するで先に固めておきます

依存パッケージを定期的に更新する

自分のコードに問題がなくても、使っているライブラリに弱点が見つかることがあります。OWASP Top 10でも、脆弱で古くなったコンポーネントの利用は主要なリスクとして挙げられています。

パッケージ管理ツールの監査コマンド（npm audit など）を月に一度実行します
重大と報告された更新から順に適用します
更新後は初めて作ったアプリを自分で確認する方法の一周で動作を確認します

GitHubを使っている場合は、依存関係の警告を自動で知らせる機能を有効にしておくと、確認の起点を自動化できます。

公開前のセキュリティ最小チェック

[ ] 入力の確認をサーバー側で行っている
[ ] データベースへの命令にプレースホルダーを使っている
[ ] 認証を自作していない
[ ] データを返す前に「その人のものか」を確認している
[ ] 全ページがHTTPSで配信される
[ ] エラー画面が内部情報を表示しない
[ ] 秘密情報がコードと履歴に含まれていない
[ ] 依存パッケージの監査を実行した

このリストは個人開発を公開する前のチェックリストと合わせて使ってください。

次に読む記事

事故に備えるもう一つの柱は、データを失わないことです。バックアップと復元を小さく仕組み化するで復元まで含めて準備してください。決済を扱う場合は個人開発の決済導入を設計するも確認が必要です。

個人開発のセキュリティを最初の一歩から固める