Webアプリを公開するというのは、誰でも触れる場所にアプリを置くということです。個人開発では、専門家のようにすべての対策を網羅するのは現実的ではありませんし、その必要もありません。大事なのは、優先順位をつけて手を打つことです。公開した瞬間から働き始める攻撃の性質を踏まえたうえで、最初に押さえておきたい3つの対策、次に効いてくる3つの対策、そして事故が起きた後に戻せるようにする備えまでを、個人開発の限られた時間で回せる形に整理します。
公開した瞬間から、攻撃は自動で始まっています
Webアプリを公開するというのは、インターネット上の誰でもアクセスできる場所に、そのアプリを置くということです。ここで見落とされがちなのが、攻撃は人が狙って始めるとは限らないという点です。公開されているアドレスを機械的に探して回るプログラムが、常にネットワーク上を動き続けています。
つまり、まだ誰にも知られていない、アクセス数の少ないアプリだから安全ということにはなりません。むしろ公開されたばかりのサービスほど設定の抜けが残っていることが多く、機械的な走査に見つかりやすい面もあります。「アクセスが増えてから対策すればいい」という順番は、成立しにくいと考えておいたほうが安全です。
これは脅すための話ではなく、優先順位を考えるための前提です。狙われる可能性がゼロにならない以上、個人開発でも公開する時点で最低限の備えは終わらせておく、という考え方に切り替えておくと、後の判断がぶれにくくなります。
最初に押さえておきたい3つ
1つめは、通信を暗号化することです。ユーザーがアプリとやり取りする内容が、途中で第三者に読み取られたり書き換えられたりしないようにする仕組みで、今はほとんどのホスティングサービスで標準的に設定できます。公開前に、この設定が有効になっているかを必ず確認してください。
2つめは、人のデータを預かるなら、ログインまわりの仕組みを自分だけで組み立てすぎないことです。パスワードの保管や認証の作りは、間違えたときの影響が大きいうえに、正しく作るには専門的な知識が要ります。信頼できる仕組みを使い、判断に迷う部分は専門家や公式ドキュメントで確認する姿勢が安全です。
3つめは、管理画面や設定ファイルを、公開範囲の外に置くことです。運用のために自分だけが使う画面や、接続情報が書かれたファイルが、一般のユーザーと同じ場所からアクセスできる状態になっていないか、公開前にひと通り確認しておきましょう。
次に効いてくる3つ
4つめは、入力された値をそのまま信用しないことです。フォームやURLを通じて送られてくる情報は、必ずしも想定通りの形で届くとは限りません。想定外の形式や長さの値が来たときにどう扱うかを、受け取る側であらかじめ決めておくことが土台になります。
5つめは、権限を必要な範囲に絞ることです。開発中は何でもできる状態のほうが楽なので、そのまま公開してしまいがちですが、一か所が突破されたときの被害の大きさは、そこから触れる範囲の広さで決まります。機能ごとに、本当にその権限が要るかを見直してみてください。
6つめは、依存しているライブラリを更新し続けることです。自分で書いたコードだけでなく、取り込んで使っている部品にも不具合が見つかることがあり、古いバージョンのまま放置していると、そこが弱点として残り続けます。更新の通知を溜め込まない仕組みを作っておくと安心です。
事故は「起きない」ではなく「起きた後に戻せる」前提で
ここまでの対策をどれだけ積み重ねても、絶対に事故が起きないとは言い切れません。個人開発で目指すべきは、事故そのものをゼロにすることよりも、起きたときに元の状態へ戻せるようにしておくことです。この前提に立つだけで、備えの優先順位はかなりはっきりします。
そのために欠かせないのが、定期的なバックアップです。データが失われたり書き換えられたりしたときに、いつの時点まで戻せるかが、復旧にかかる時間を大きく左右します。手動で忘れずに、ではなく自動で残る仕組みにしておくほうが安全です。
もう一つが、何が起きたかを後から追える記録を残しておくことです。いつ、どこから、どんなアクセスがあったかの記録があれば、異常に気づいたときの原因の絞り込みが早くなります。記録を取ること自体はそれほど難しくないので、公開前に有効にしておきましょう。
個人開発では、やりすぎなくていい部分もあります
守りを固めようとするほど、あれもこれもと手を広げたくなりますが、個人開発の時間には限りがあります。優先順位の低い部分にまで手を伸ばすと、かえって肝心な部分が手薄になりかねません。
たとえば、独自の暗号方式を自分で考えるのは避けたほうが無難です。広く使われて検証されてきた仕組みのほうが、個人が新しく考えるものより信頼性が高いのが実情です。同じように、大規模なサービス向けの構成をそのまま真似る必要もありません。今の規模に合った対策から、順番に積み上げていけば十分です。
「やっていないことがある」ことに不安を感じすぎる必要もありません。優先順位の高い対策から順に終わらせていく、というだけで、個人開発として十分な水準には届きます。
守りの仕事は終わらないので、運用に組み込む
セキュリティの対策は、一度やって終わりではなく、公開している限りずっと続く仕事です。新しい弱点が見つかったり、周りの状況が変わったりするたびに、見直しが必要になります。開発の時間配分の中に、最初から守りのための時間を組み込んでおくと無理なく続けられます。
とはいえ、守りに時間を取られすぎて、肝心の集客や改善が止まってしまっては本末転倒です。判断に時間のかかる調べ物は、道具を使って短くする工夫も有効です。たとえばAppLupeのようなキーワード調査ツールを使えば、アプリが探されやすいかどうかの確認を短い時間で済ませられるので、守りに手を割きながらも集客の歩みを止めずに済みます。
最初の3つ、次の3つ、そして戻すための備えという順番で手を打っていけば、個人開発でも十分に現実的な守りができます。完璧を目指すより、崩れたときに戻れる状態を保つことを合格ラインにしておきましょう。
よくある質問
Q. 小さな個人開発のアプリでも、セキュリティ対策は必要ですか？
必要です。攻撃の多くは、規模や知名度に関係なく、公開されているアドレスを機械的に探して回る形で始まります。そのため、利用者がまだ少ない段階でも無防備な状態は避けたほうが安全です。公開する時点で、優先順位の高い対策から先に済ませておくことをおすすめします。
Q. セキュリティ対策は、具体的に何から始めればいいですか？
まずは、通信の暗号化・認証まわりを自作しすぎないこと・管理画面や設定ファイルを公開範囲の外に置くこと、という3つが土台になります。ここが整ってから、入力値の扱いや権限の絞り込み、依存ライブラリの更新といった次の対策に進むと、無理なく積み上げていけます。
Q. 全部の対策をやりきる自信がないのですが、公開しても大丈夫ですか？
完璧を目指す必要はありません。個人開発で現実的な目標は、事故が起きないことよりも、起きた後に元へ戻せることです。バックアップと、何が起きたか後から分かる記録だけは先に整えたうえで、残りは優先順位に沿って少しずつ手を入れていけば十分です。
AppLupe（アップルーペ）運営ツールこのブログを運営しているAppLupeは、App Store対応のASOツールです。「作ったアプリが検索で見つからない」を解決するために、キーワード調査から順位計測までを1つにまとめています。
- キーワードの検索ボリューム（AppLupe指数）と関連キーワードを確認
- 競合アプリがどのキーワードから流入しているかを実測
- AIがタイトル・サブタイトル・スクリーンショットの改善案を自動生成
- 狙ったキーワードの検索順位を毎日自動トラッキング