技術記事

アプリやWebサービスを外部に発注するとき、多くの方が不安に思うのが「セキュリティは大丈夫だろうか」という点です。

個人情報の流出、アカウントの乗っ取り、不正アクセス、身に覚えのない高額請求——ニュースで見かけるこうした事故は、多くの場合「作るときにきちんと対策していなかった」ことが原因で起こります。

micomiaでは、セキュリティ対策を「余裕があれば追加するオプション」ではなく、すべての案件に最初から組み込む標準の作り方として定めています。この記事では、私たちが実際にどんな対策を行っているのかを、専門用語をひとつずつ解説しながらご紹介します。

はじめに — micomiaのセキュリティに対する考え方

具体的な対策の前に、私たちが大切にしている2つの考え方をお伝えします。

1. 「画面で防いだから安全」とは考えない

多くの不十分なアプリは、「入力チェックを画面側でやっているから大丈夫」と考えてしまいます。しかしこれは危険な思い込みです。

アプリやWebサービスは、裏側でサーバー（データを保管し処理を行うコンピューター）とやりとりをしています。悪意のある人は、アプリの画面を通さず、このサーバーに直接不正なデータを送りつけることができます。専門的な道具を使えば、画面のチェックをすべて素通りしてサーバーを攻撃できてしまうのです。

そのためmicomiaでは、画面側とサーバー側の両方で、それぞれ独立してチェックを行います。

2. 「攻撃する側の視点」で作る

守りを固めるには、攻撃の手口を知る必要があります。
micomiaは、実際に使われる攻撃手法を一つひとつ想定し、それぞれに対策を用意しています。
この記事で紹介する対策は、いずれも「こういう攻撃があるから、こう防ぐ」という具体的な対になっています。

以下、スマートフォンアプリ編（iOS / Android）とWeb編（ウェブサイト・管理画面）の2部構成でご説明します。お客様がご検討中のサービスに合わせて、関係する部をお読みください。

第1部　スマートフォンアプリ編（iOS / Android）

iPhone・Android向けのアプリで、私たちが行っている対策です。スマホアプリは「アプリストアからインストールして使う」という特性があり、それを生かした対策も含まれます。

第1章　正規のアプリからのアクセスだけを受け付ける

どんな脅威か：悪意のある人は、お客様の本物のアプリを分解して中身を調べ、「アプリのふりをした偽のプログラム」を作ってサーバーに大量のリクエストを送りつけることがあります。こうなると、アプリの画面上でいくら対策をしても意味がありません。

micomiaの対策：App Check（アップチェック）という仕組みを導入します。これは、サーバーにアクセスしてきた相手が「本当にアプリストアからインストールされた本物のアプリか」を、その都度確認する技術です。

• iPhoneでは App Attest、Androidでは Play Integrity という、AppleとGoogleが提供する公式の証明機能を使います。これにより「本物の端末で動く本物のアプリ」だけを通し、偽物や不正な道具からのアクセスは拒否します。

• この対策は、Firebase（Googleが提供するアプリ基盤。micomiaが標準採用しています）を使うすべての案件で常時有効にしています。

第2章　すべての通信を暗号化する

どんな脅威か：スマホとサーバーの間でやりとりされるデータ（ログイン情報や個人情報など）が暗号化されていないと、公共のWi-Fiなどで通信を盗み見られる危険があります。

micomiaの対策：すべての通信を HTTPS（通信内容を暗号化して送受信する仕組み。ブラウザの鍵マークでおなじみのものです）で行います。内部的には TLS（通信を暗号化する技術）の安全なバージョンのみを使用し、古くて脆弱な方式は使いません。micomiaが標準採用するGoogleの基盤では、この暗号化が自動的に最新の水準で保たれます。

第3章　アプリの中に「鍵」を隠さない

どんな脅威か：アプリを動かすには、外部サービスと連携するための「鍵」（APIキーやパスワードなど、システムを利用する権限を証明する文字列）が必要です。これをアプリの中にそのまま書き込んでしまうと、アプリを分解されたときに鍵を盗まれ、悪用されます。特に、システムのすべての操作ができてしまう最上位の鍵が漏れると、データの全消去すら可能になります。

micomiaの対策：

• 最上位の権限を持つ鍵は、アプリ側には一切置かず、サーバー側だけで厳重に管理します。

• 一般の鍵も、プログラムに直接書き込まず、外部の秘密情報管理サービスで管理します。

• 開発中も、AIツールなどが誤って鍵ファイルを読み書きしないよう、アクセス制限を設定しています。

第4章　本人確認と権限の管理（認証・認可）

どんな脅威か：「ログインさえしていれば何でもできる」という作りだと、一般利用者が管理者だけの機能を使えてしまったり、他人の情報を閲覧できてしまったりします。

micomiaの対策：2つを明確に分けて管理します。

• 認証（あなたが誰かを確認すること）：ログイン処理を一箇所に集約し、すべての保護された機能でもれなく確認します。画面ごとにバラバラにチェックを書くと抜け漏れが起きるためです。

• 認可（あなたに何をする権限があるかを確認すること）：利用者の役割（一般利用者・管理者など）ごとに「できること」を明確に定義し、権限のない操作は拒否します。

第5章　他人のデータを勝手に触らせない

どんな脅威か：IDOR（アイドア／不正な直接オブジェクト参照）と呼ばれる、非常によくある攻撃です。たとえば「注文番号1001は自分の注文」だと分かったとき、番号を1002に書き換えて送ると他人の注文情報が見えてしまう——といった手口です。「ログインしているか」しか確認していないと成立してしまいます。

micomiaの対策：リクエストのたびに「ログインしているか」だけでなく、「この利用者が、まさにこのデータの持ち主か」をサーバー側で必ず確認します。持ち主でなければ、たとえログイン済みでも拒否します。データベース側でも同じ確認を二重に行います。

第6章　パスワードを守る

どんな脅威か：パスワードは複数の角度から狙われます。

• 総当たり攻撃（ブルートフォース）：1つのアカウントに対して、パスワードを片っ端から試す手口。

• パスワードスプレー攻撃：逆に、Password123のような「ありがちなパスワード」1つを、大量のアカウントに少しずつ試す手口。1アカウントあたり1〜2回しか試さないため、単純な「◯回間違えたらロック」では捕まえられません。

micomiaの対策：

• 一定回数パスワードを間違えると、そのアカウントを一時的にロックします。

• それに加えて、サービス全体を横断して「同じパスワードが多数のアカウントに試されていないか」を監視し、異常を検知したら追加の確認（画像認証など）や一時ブロックを行います。

• 登録・変更時に、ありがちなパスワードや過去に流出したことが知られているパスワードを拒否します（照合は安全な方式で行い、パスワードそのものを外部に送ることはありません）。

第7章　なりすまし・乗っ取りへの備え（アカウントの状態管理）

どんな脅威か：退会したり、利用停止になったりしたアカウントが、いつまでもログインできる状態だと、乗っ取りや不正利用の温床になります。

micomiaの対策：アカウントの状態を「登録中」「利用中」「利用停止」「退会」といった段階で明確に管理します。利用停止や退会にした瞬間に、そのアカウントのログイン状態を即座に無効化し、二度とアクセスできないようにします。重要な操作や管理者には、二段階認証（パスワードに加えて、スマホに届くコードなどでもう一段確認する仕組み）を必須にできます。

第8章　二重操作を防ぐ

どんな脅威か：通信が遅いときに送信ボタンを何度も押してしまい、同じ購入や送金が二重・三重に実行される事故。利用者に金銭的な被害が及びます。

micomiaの対策：

• ボタンは一度押したら、処理が終わるまで押せないようにします（画面側）。

• さらにサーバー側でも、同じリクエストが重複して届いても1回だけしか処理しない仕組み（冪等性＝べきとうせい：何回同じ操作をしても結果が1回分になる性質）を組み込みます。この二層で、二重実行を確実に防ぎます。

第9章　写真・動画アップロードの安全対策

どんな脅威か：巨大なファイルを大量に送りつけてサーバーをパンクさせる攻撃や、ファイルを装った不正なデータの混入。また、スマホで撮った写真には撮影場所の位置情報が埋め込まれていることがあり、そのまま公開すると自宅などが特定される恐れがあります。

micomiaの対策：

• アップロードできるファイルのサイズと形式を制限し、想定外の巨大ファイルや不正な形式を拒否します。

• 写真に含まれる位置情報などのデータを、公開前に自動で削除します。意図しない居場所の特定を防ぎます。

• 画像は適切なサイズに変換してから保存し、表示速度と安全性を両立します。

第10章　入力データのチェック

どんな脅威か：入力欄に不正な文字や命令を紛れ込ませ、システムを誤作動させるインジェクション攻撃はデータベースを操作されたり、情報を抜き取られたりします。

micomiaの対策：すべての入力欄に文字数の上限を設け（巨大なデータの送りつけを防止）、想定される形式かどうかを画面とサーバーの両方で検証します。micomiaが標準採用するデータベース（Firestore）に対しても、専用の攻撃手口（NoSQLインジェクション）を想定した検証を行い、不正な命令を混入できないようにしています。

第11章　使いすぎ・攻撃によるコスト暴走を防ぐ

どんな脅威か：現代のクラウドサービスは「使った分だけ課金」が基本です。そのため、大量のアクセスを浴びせる攻撃（DDoS＝ディードス）を受けると、サービスが重くなるだけでなく、利用料金が想定外に跳ね上がるリスクがあります。

micomiaの対策：

• サーバーが自動で増える上限を設定し、攻撃を受けても際限なく費用が膨らまないようにします。

• 短時間に異常な回数のアクセスを繰り返す相手を、自動的に制限します。

• 月額予算に対して50%・80%・100%に達したら通知が飛ぶアラートを設定し、異常を早期に察知します。

• サービスの規模やリスクに応じて、より高度な防御（専用の防御サービスやボット対策）を追加するかどうかを判断します。過剰な対策でコストをかけすぎることも避け、規模に見合った守りを設計します。

  
  

第2部　Web編（ウェブサイト・管理画面）

ブラウザで使うWebサービスやWebサイト、管理画面で、私たちが行っている対策です。Webにはブラウザ特有の攻撃が数多く存在し、それぞれにきめ細かい対策が必要です。

第1章　不正なスクリプトを実行させない（最重要）

どんな脅威か：XSS（クロスサイトスクリプティング）は、Webで最も多い攻撃のひとつです。掲示板の投稿やコメント、プロフィール欄などに不正なプログラム（スクリプト）を紛れ込ませ、それを閲覧した他の利用者のブラウザで勝手に動かす手口です。これによりログイン情報を盗まれたり、なりすまし操作をされたりします。XSSには3つのタイプがあり、micomiaはそのすべてに対策します。

• 反射型：罠のURLを踏ませ、その場でスクリプトを実行させるタイプ。

• 格納型：投稿などとしてサーバーに保存され、閲覧するたびに何度も発動するタイプ。被害範囲が広く、特に投稿内容が管理者の画面に表示される場合、管理者の権限が乗っ取られる最悪のケースにつながります。お問い合わせフォーム経由が典型的な狙われ方です。

• DOMベース型：ブラウザ内部の処理を悪用するタイプ。

micomiaの対策：入力された内容から危険な部分を入力時と保存時の両方で無害化し、画面に表示する際にも安全な形に変換します。生のプログラムを画面に流し込む危険な書き方は原則禁止とし、コード審査で残っていないことを確認します。

第2章　最後の砦をつくる（CSP・Trusted Types）

どんな脅威か：万が一、前章の対策をすり抜けて不正なスクリプトが紛れ込んでしまった場合の「最後の砦」も必要です。

micomiaの対策：CSP（コンテンツセキュリティポリシー）という仕組みを導入します。これは、ブラウザに対して「このページで動かしてよいプログラムはこれだけ」とあらかじめ宣言しておく仕組みで、許可していないスクリプトはたとえ紛れ込んでも実行されません。さらに Trusted Types という、危険な処理に安全なデータしか渡せなくする仕組みも組み合わせ、二重・三重に守ります。これらは、いきなり有効にするとサイトの正常な機能まで止めてしまうことがあるため、まず「記録だけして遮断はしない」モードで問題がないか確認してから本番適用する、という慎重な手順を踏みます。

第3章　意図しない操作をさせない（CSRF）

どんな脅威か：CSRF（シーサーフ／クロスサイトリクエストフォージェリ）は、ログイン中の利用者を罠のページに誘導し、本人が気づかないうちに、勝手に設定変更や送金などを実行させる攻撃です。利用者は何も操作していないつもりなのに、裏で処理が走ってしまいます。

micomiaの対策：まず、そのサービスの認証方式がこの攻撃を受けうるかを判定します（受けにくい方式を採用している場合はその旨を記録します）。対策が必要な場合は、正規の画面からの操作にだけ付与される「合言葉」を照合し、外部の罠ページからのリクエストを拒否します。あわせて、データを変更する操作は必ず適切な方式で行い、リンクを踏んだだけで実行されるような作りを避けます。

第4章　画面の乗っ取り・偽装を防ぐ（セキュリティヘッダ）

どんな脅威か：クリックジャッキングと呼ばれる、お客様のサイトを透明な状態で罠サイトに重ね、利用者が気づかないうちに「いいね」や購入ボタンを押させる攻撃などがあります。

micomiaの対策：ブラウザに送るセキュリティ用の指示（セキュリティレスポンスヘッダ）を明示的に設定します。

• お客様のサイトを他のサイトに埋め込ませない設定で、クリックジャッキングを防ぎます。

• ファイルの種類を誤認させる攻撃を防ぐ設定を加えます。

• URLに含まれる情報が外部サイトに漏れないよう、送信範囲を制限します。

• カメラや位置情報など、端末の機能を使わない場合は明示的に無効化し、外部部品による悪用を防ぎます。

第5章　偽サイトへの誘導を防ぐ（オープンリダイレクト）

どんな脅威か：「ログイン後に元のページへ戻す」といった転送機能を悪用し、お客様のサイトを経由して偽サイトへ誘導する手口です。利用者は信頼できるサイトのリンクだと思って踏むため、フィッシング詐欺に引っかかりやすくなります。

micomiaの対策：転送先として外部から指定されたURLを、そのまま信用しません。あらかじめ許可した行き先か（完全に一致するか）を厳密に確認し、少しでも疑わしい場合は安全な既定のページに戻します。巧妙な偽装のバリエーションも想定して判定します。

第6章　サーバー内のファイルを守る（ディレクトリトラバーサル）

どんな脅威か：ディレクトリトラバーサル（横断）は、ファイル名の指定に../のような記号を紛れ込ませ、本来アクセスできないサーバー内部のファイル（設定ファイルやパスワード情報など）を読み出す手口です。

micomiaの対策：ファイルを扱う箇所では、指定された場所が許可された範囲の中に収まっているかを必ず確認します。危険な記号やその変形（記号を暗号化して紛れ込ませる手口）も想定して検証し、範囲外へのアクセスを拒否します。

第7章　暗号化されない通信の混入を防ぐ（混在コンテンツ）

どんな脅威か：混在コンテンツとは、暗号化された安全なページの中に、暗号化されていない部品（画像や外部プログラムなど）が混ざっている状態です。安全なはずのページに弱点が生まれ、機能が突然動かなくなる原因にもなります。

micomiaの対策：ページを構成するすべての部品を暗号化された経路で読み込むようにし、暗号化されていない読み込みが紛れ込んでいないかを開発時のチェックで検出・排除します。

第8章　外部から読み込む部品の改ざんを防ぐ（SRI）

どんな脅威か：Webサイトは、外部の配信サービス（CDN）から便利な部品を読み込むことがあります。もしその配信元が乗っ取られて部品がすり替えられると、お客様のサイトを通じて利用者に不正なプログラムが配られてしまいます（サプライチェーン攻撃）。

micomiaの対策：SRI（サブリソース整合性）という仕組みで、読み込む部品の「正しい中身の指紋」をあらかじめ記録しておきます。中身が少しでも書き換わっていれば、ブラウザが読み込みを拒否します。あわせて、部品のバージョンを固定し、勝手に別のものへ差し替わらないようにします。

第9章　通信とアクセス元の保護

どんな脅威か：Webでも、通信の盗聴や、他サイトからの不正なデータ利用のリスクがあります。

micomiaの対策：

• すべての通信を暗号化（HTTPS）し、暗号化されていないアクセスは自動で暗号化されたページへ転送します。あわせて、一度アクセスしたら以降は必ず暗号化通信を使うようブラウザに記憶させる設定（HSTS）を行います。

• ログイン情報を保持するCookie（クッキー：ブラウザに保存される小さなデータ）には、盗み見や悪用を防ぐ安全設定を付与します。

• アクセスを許可する接続元を限定し（CORS）、許可していないサイトからのデータ利用を防ぎます。ただしこれは万能ではないため、前述の認可チェックと組み合わせて守ります。

第10章　管理画面の保護

どんな脅威か：個人情報や売上などを扱う管理画面は、特に厳重な保護が必要です。担当者が席を離れた隙に他人に操作される、エラー画面から内部情報が漏れる、といったリスクがあります。

micomiaの対策：

• 一定時間操作がない場合、自動的にログアウトします（事前に警告も表示します）。第三者による盗み見や操作を防ぎます。

• エラーが起きても、システムの内部構造やデータベースの情報が画面に表示されないようにします。攻撃のヒントを与えないためです。また「登録されていないメールアドレスです」といった表示で会員の有無が分かってしまわないよう、メッセージも配慮します。

第11章　検索から非公開情報が漏れないようにする

どんな脅威か：検索機能は便利な反面、作り方を誤ると本来見えないはずの非公開データや他人の情報が検索結果に出てきてしまうことがあります。

micomiaの対策：検索結果を画面側で隠すだけの実装は行いません。「その利用者が見てよいデータだけ」を検索の段階で絞り込むようにし、権限のない情報は最初から結果に含めません。検索欄への不正な入力への対策や、検索履歴に含まれる個人情報の保護も行います。

おわりに — 「作って終わり」にしない品質管理

個別の対策に加えて、micomiaは開発の進め方そのものにも安全のための仕組みを組み込んでいます。

• リリース前のセキュリティチェック：ここまで紹介した対策が実際に機能するか、公開前に一つひとつ確認する工程を設けています。実際に攻撃を模したテストを行い、防げていることを確かめます。

• 部品の脆弱性を継続監視：アプリは多くの外部部品を組み合わせて作られます。それらに新たな弱点が見つかっていないかを継続的にチェックし、危険度の高いものは速やかに更新します。

• インフラ設定の事故防止：サーバーの設定変更は、担当者が管理画面から手作業で行うのではなく、記録・確認を経た手順で行うルールにしています。過去に、手作業の設定ミスで料金が暴騰した事例を教訓にしたものです。

• 脆弱性が見つかったときの対応：万が一弱点が見つかった場合、対策が完了する前に公表しないという原則で対応します。公表が攻撃を誘発するのを防ぐためです。修正完了後、必要に応じてお客様や利用者にご報告します。

お客様へ

ここまでご紹介したように、micomiaはセキュリティを「あとから足すもの」ではなく、最初の設計から組み込むものとして、すべての案件で標準的に実施しています。上記の多くは、お客様から特別にご指定いただかなくても、私たちの標準の作り方として含まれます。

「うちのサービスの場合はどこまで必要？」「この対策の費用感は？」といったご相談も承っております。お客様のサービスの規模やリスクに合わせて、過不足のない守りをご提案いたします。まずはお気軽にお問い合わせください。

本記事は、micomiaが全開発案件に適用しているセキュリティ規範にもとづいて作成しています。記載の対策は、お客様のサービスの構成・規模により、適用範囲を最適化してご提供します。