HarmonyOS 6におけるセキュリティ品質テスト実践ガイド——テスト実行から脆弱性修正まで完全手順書

HarmonyOS 6アプリケーションをAppGallery Connect(AGC)に提出する際、**セキュリティ品質テスト(Security Basic Quality Test)**​を省略してしまう開発チームは非常に多いです。その後、AGCによる審査でリジェクトされたり、セキュリティスキャンで重大な脆弱性を検出されてから慌てて修正に取り組むことになります。HuaweiはDevEcoツールチェーンと検出ルールを提供しており、権限の悪用、平文データ保存、コンポーネントセキュリティ設定、WebViewセキュリティ設定といった一般的なリスクを検査できます。

本記事では、「設定 → 実行 → レポート確認 → 典型的な問題修正」の完全ループを手順を追って解説します。应用程序がセキュリティ要件を満たした上でリリースされることを保証します。

一、セキュリティ品質テストの概要

1. テスト項目とは?

セキュリティ品質テストは、アプリケーションパッケージ(HAP/HSP)に対する静的ルールスキャン + ランタイム動作検出を実施し、以下の項目を重点的にカバーします。

検出項目 説明
権限の最小化​ 使用していない権限や危険な権限(例:READ_CONTACTSの呼び出しがない状態)を申請していないか
機密データの保護​ Prefs/データベース/ファイルにパスワードやトークンを平文で保存していないか
WebViewセキュリティ​ setJavaScriptEnabled(true)を有効にしている場合、WebMessagePortの制限や平文HTTPの無効化が行われているか
コンポーネントエクスポートリスク​ Ability/Service/DataAbilityのvisibleが誤ってtrueに設定されていないか
ログ情報漏洩​ リリースビルドにconsole.log/hilog.debugで機密フィールドを出力するコードが残っていないか

2. テストの実行者

  • DevEco Studio組み込み検出:Build > Run Inspection By Name > HarmonyOS Security Check
  • コマンドライン/CI環境:hvigorw assembleHap --mode module -p securityCheck=true(DevEco 4.x以降が必要)
  • AGC提出前のスキャン:HAPアップロード後、AGCの「アプリケーションセキュリティ検出」でトリガー

二、セキュリティ品質テストの実行方法

1. DevEco Studio GUIで実行(初回推奨)

  1. プロジェクトを開き、Build HAP(s)が成功していることを確認します。
  2. メニューから Code → Inspect Code… を選択します。
  3. ポップアップウィンドウで HarmonyOS Security Check を選択(またはRun Inspection By NameでHarmonyOSと検索)
  4. Whole Project​を選択し、OKをクリックします。
  5. 下部の Inspection Results​パネルにすべてのセキュリティ問題が重大度順(Error > Warning > Typo)で表示されます。

2. コマンドライン/CIで実行(自動化に適しています)

# プロジェクトルートで実行(Windowsはhvigorw.batを使用)
./hvigorw assembleHap --mode module -p securityCheck=true

# HTML形式レポートを生成(一部バージョンで対応)
./hvigorw assembleHap --mode module -p securityCheck=true -p securityReportFormat=html

ビルド完了後レポートは以下に出力されます:

<module>/.inspection/
  harmonyos-security-report.xml   # マシンリーダブル版
  harmonyos-security-report.html  # 人工閲覧用(対応している場合)

三、テストレポートの確認与分析

1. IDE内で直接分析(最も高速)

Inspection Resultsパネルはファイルごとにグループ化されており、クリックでソースコードの該当行にジャンプできます:

️ Security - WebView allows JavaScript execution without restricted interface [Error]
   ↳ entry/src/main/ets/pages/WebPage.ets:23
   ↳ Recommendation: Disable JS or restrict via WebMessagePort

各問題には以下が含まれます:

  • 問題の内容:具体的な違反事項
  • 発生箇所:ファイル名 + 行番号
  • 修正提案:公式が推奨する修正方法

2. XML/HTMLレポートのフィールド解説

<problem type="SECURITY" severity="ERROR" file="WebPage.ets" line="23">
  <description>
    WebView JavaScript enabled without WebMessagePort restriction
  </description>
  <fix-suggestion>
    Use setWebMessagePort() to restrict JS-to-ArkTS communication,
    or disable setJavaScriptEnabled if not required.
  </fix-suggestion>
</problem>

特に注意すべきは severity="ERROR" の項目です——AGC審査では通常、Errorレベルの問題をすべて修正することが求められます。Warningレベルは修正推奨ですが、必須ではありません。

四、よくあるセキュリティ問題と修正實際

1. WebViewでJSを有効にしているが通信が制限されていない(最も頻出)

レポートでの表示:

WebView allows JavaScript execution without restricted interface

問題のあるコード:

// ❌ リスク:JS実行を有効にしているがメッセージポートが制限されていない
Web({ src: url, controller: this.controller })
  .javaScriptAccess(true)  // setJavaScriptEnabled(true)に相当

修正方法:

// ✅ 方法A:JS連携が不要な場合は無効化
Web({ src: url, controller: this.controller })
  .javaScriptAccess(false)

// ✅ 方法B:JS連携が必要な場合、WhiteList方式でWebMessagePortを通じて通信
this.controller.setWebMessagePort([restrictedPort]);
Web({ src: url, controller: this.controller })
  .javaScriptAccess(true)

2. Abilityが不必要にエクスポートされている(exported: true)

レポートでの表示:

Exported UIAbility/Service without necessity

問題のある設定(module.json5):

{
  "abilities": [{
    "name": ".MainAbility",
    "exported": true   // ❌ エントリポイント以外のAbilityはエクスポート不要
  }]
}

修正方法:エントリポイントAbility(skillsにaction.system.homeを含む設定のもの)のみexported: trueとし、それ以外はfalseに設定するか省略(デフォルトはfalse)。

"exported": false

3. Preferencesにトークンを平文で保存

レポートでの表示:

Sensitive data stored in plain text in Preferences

修正原則:

  • トークン/パスワードはローカル保存すべきではないため、Account Kitでの管理、またはサーバーサイドでの保存を優先します。
  • 短期トークンのキャッシュが必要な場合は、@ohos.security.cryptoFrameworkを使用してAES暗号化してからPreferencesに書き込み、読み込み時に復号化します。
// 暗号化して保存するサンプルコード
const cipherData = await aesEncrypt(userToken, masterKey);
preferences.put('secure_token', cipherData);

4. リリースビルドにデバッグログが残っている

レポートでの表示:

Debug log calls found in release build

修正方法:

  • ログユーティリティをラップし、Release環境ではhilog.debug/infoを実行しないようにします。
  • または、難読化ルール(obfuscation-rules.txt)に以下を追加:
-dont-obfuscate-source-file-names
-remove-unused-code

さらに、カスタム条件付きコンパイル__RELEASE__を使用してログの切り替えを制御します。

五、落とし穴回避とベストプラクティス

シナリオ 推奨事項
実行タイミング​ リリースごと、、新規WebView/Ability/権限追加後は必須
ブロッキング基準​ Errorレベルの問題を 0件 にしてからAGCに提出
CIへの統合​ Jenkins/GitLab CIにsecurityCheck=trueを追加し、XML解析失敗時はパイプラインを失敗扱い
レポート保管​ HTML/XMLレポートを提出時の添付資料として保存
誤検知への対応​ 合理的なケース(例:Demo AppでAbilityをエクスポートする必要がある場合)はAGCで理由を追記

六、まとめ:セキュリティ品質テスト標準手順書

  1. HAPビルド​ → 2. Devecoで HarmonyOS Security Check 実行​ → 3. Errorレベルの問題を一つずつ確認​ → 4. 提案に基づいてコード/設定を修正​ → 5. 再実行してErrorが0件になるまで繰り返す​ → 6. レポートを保存して提出

核心の原則:HarmonyOS 6の提出プロセスにおいて、セキュリティ品質テストはオプションではなく、最初の守護者です。早期に実行・修正することで、AGC審査でのリジェクトとやり直しを防ぎましょう。

タグ: HarmonyOS セキュリティテスト DevEco AGC webview

10月6日 02:35 投稿