JSON・APIレスポンスから個人情報や秘密情報を除去する方法

キー名から確認対象を探す

apiKey、accessToken、secret、password、cookie、email、phone、addressは代表的な確認対象です。ただし独自の略称や日本語キーもあるため、キー名だけの自動判定には頼れません。

requestIdやtimestampのように一見安全な値でも、内部ログと照合できる識別子になる場合があります。共有目的に不要なら置き換えます。

JSONを安全に加工する手順

1. HTTPヘッダーやCookieを分離し、レスポンス本文だけを共有用にコピーします。
2. 認証情報、個人情報、内部識別子をキーと値の両面から確認します。
3. 文字列は架空値、数値は桁数が分かる値へ置き換え、nullや真偽値は必要に応じて残します。
4. 整形後にJSONとして解析できることと、配列の後半に実データが残っていないことを確認します。

型を保つ理由

JSON本体だけでなく、スクリーンショットに写るURL、開発者ツールのヘッダー、ファイル名にも注意してください。

具体例：注文APIのレスポンスを共有する

注文APIにはcustomerId、email、address、accessTokenのような分かりやすい項目だけでなく、自由記述欄やネストした配列内にも個人情報が入ることがあります。

数値を文字列へ変えると、型に依存する不具合を再現できません。数値は数値、真偽値は真偽値のまま扱い、キーと配列の位置関係を保持します。

1. 整形済みJSONとして解析できることを先に確認します。
2. 認証、顧客、住所、注文、メタデータの各階層を順番に確認します。
3. キー、文字列、数値の対象を選んでマスキングします。
4. 結果を右クリックで部分解除する場合も、公開してよい値だけに限定します。

JWTはピリオド区切りの文字列でも内部に利用者情報を含む場合があります。途中だけを残さず、トークン全体を置換してください。

よくある質問

JSONのキー名もマスキングした方がよいですか？

公開APIの一般的なキーは残せますが、社内業務名、顧客固有項目、未公開機能名が含まれる場合はキーも対象にします。

null、true、falseも隠す必要がありますか？

通常は機密値ではなく処理条件の再現に役立つため残します。ただし存在自体が機密となる属性は、項目全体の削除も検討してください。