はじめに
モバイルアプリでは、「ユーザーの権限によってページやボタンの表示・操作を制限したい」という要件がよくあります。
例えば：
- 一般ユーザーは一覧ページだけ見えるが、編集や削除は不可
- 管理者だけがダッシュボードやレポート出力を操作できる
本記事では、業界標準に基づいた安全な権限制御の仕組みを以下の観点から解説します。
権限制御の基本構成（3層モデル）
| 層 | 目的 | 処理 |
|---|---|---|
| 前端（App） | 表示・操作の制御 | ページ・ボタンを権限により制御 |
| 後端（API） | 真正な認可（Authorization） | すべてのアクセス要求を強制的に検査 |
| 通信レイヤー | 安全性 | HTTPS, Token, 署名などを活用 |
権限設計の基本（RBAC）
RBAC（ロールベースアクセス制御）は以下のような構成で動作します：
- ユーザー（User）
- ロール（Role）
- 権限コード（Permission Code）
権限コードの命名例（おすすめ）：
user:view → ユーザー一覧を閲覧できる
user:edit → ユーザー編集が可能
order:delete → 注文を削除できる
report:export → レポートを出力できる
UIとAPIの役割分担
| 層 | 目的 | 例 |
|---|---|---|
| UI（前端） | 見せる・隠す | 「編集」ボタンを非表示にする |
| API（後端） | 実行させる/させない | 編集APIにアクセス拒否 |
UI制御はバイパスされる可能性がある？
はい。Flutter アプリも逆コンパイルされ、次のように UI 側の if 判定をすり抜けることが可能です。
if (permissions.contains('user:view')) {
return UserPage();
}
攻撃者はコードを書き換え、常に true にしたり、制限画面へ強制遷移できます。
本当に安全な設計とは？
UI 表示制御だけで安心してはいけません。実行制御は必ず後端で行うべきです。
後端では：
-
API にアクセスするごとに user:view などの権限をチェック
-
失敗すれば 403 Forbidden を返却
-
ログイン時に JWT トークンと一緒に権限情報を付与
シリーズリスト
Flutterで作る安全な権限制御【Part 1】業界標準と設計指針のすべて
Flutterで作る安全な権限制御【Part 2】RBACを支えるデータベース設計とER図（Mermaid付き）
Flutterで作る安全な権限制御【Part 3】ページとボタンを権限で制御する実装編（go_router × Riverpod）
Flutterで作る安全な権限制御【Part 4】Flutterアプリの反編譯リスクとセキュリティ対策
Security Flutter obfuscation