はじめに
本シリーズの Part 1〜3 では、Flutter アプリにおける RBAC 権限制御の仕組み、データ構造、UI制御実装までを紹介してきました。
今回は、その仕組みを 「攻撃者に逆コンパイルされて操作されてしまう」 という前提で、
どう守るか？
どこまで前端で信用できるか？
API は本当に安全か？
を整理していきます。
リスク：Flutter アプリは逆コンパイルされる
実際に起こりうること：
-
flutter build apkしたバイナリは 逆アセンブル/逆解析可能 -
permissions.contains('user:view')の判定を強制的にtrueに書き換え - 非表示のページやボタンに無理やり遷移・表示
- REST API を直接叩く
if (permissions.contains('admin')) {
return AdminPage(); // ← 改造される
}
解決の原則：「前端は信用できない」
UI の表示制御は UX のため、
実行制御（認可）はすべて後端で行うべきです。
対策①：すべてのAPIに認可ロジックを入れる
@Get("/users")
fun listUsers(@AuthUser user: User): List<User> {
if (!user.permissions.contains("user:view")) {
throw ForbiddenException("No permission");
}
return userService.getAll()
}
攻撃者が Flutter を改造して UI を出しても、
API が拒否すれば意味がない！
対策②：Flutter 側での安全対策まとめ
| 項目 | 方法 |
|---|---|
| 通信の保護 | 全通信に HTTPS を強制 |
| トークン署名 | JWT（HMAC/RSA）を利用し、不正再送信を防ぐ |
| Secure Storage | 権限やトークンを EncryptedSharedPreferences 等に保存 |
| 改竄防止（難読化） |
flutter build apk --obfuscate --split-debug-info を使用 |
| デバイスの検知（任意） | Jailbreak / Root 検出やエミュレータのブロック |
| アプリ完全性チェック（上級） | hash 検証 / tamper check / integrity validation |
攻撃に備えたセキュリティ設計の心得
| 層 | 守るべきポイント |
|---|---|
| UI表示 | 権限に応じて見せない（ただし飾り） |
| アクション | 必ずAPIで再チェック |
| 通信 | HTTPS / JWT / 署名 / リプレイ防止 |
| 保存領域 | SecureStorage を使用して機密情報を守る |
| アプリ体 | 難読化・改竄検知・アンチデバッグなどを導入 |
最低限やるべきセキュリティ
-
APIにはすべて認可ロジックを入れる
-
トークンと権限情報は SecureStorage に保存
-
HTTPSを必ず使用する（常時SSL）
-
Flutterビルド時に難読化（--obfuscate）を有効に
-
ログイン時に取得した権限を毎回信頼せず、再チェックする
攻撃者の視点でチェックする
-
App を逆コンパイルして UI を改変
-
権限チェックの if を無視してページ表示
-
REST API に直接 POST して操作
-
ログイン後の JWT を再利用して別端末から操作
これらは全て「後端が正しく認可していれば通らない」
→ APIが最終防衛ライン
シリーズリスト
Flutterで作る安全な権限制御【Part 1】業界標準と設計指針のすべて
Flutterで作る安全な権限制御【Part 2】RBACを支えるデータベース設計とER図（Mermaid付き）
Flutterで作る安全な権限制御【Part 3】ページとボタンを権限で制御する実装編（go_router × Riverpod）
Flutterで作る安全な権限制御【Part 4】Flutterアプリの反編譯リスクとセキュリティ対策
Security Flutter obfuscation