ブラウザを信頼せず、代わりにユーザーを認証する手順を実行してください。したがって、この場合、サーバーとの通信に使用するパスワードを入力するように要求することができます。
Google 拡張機能では、AJAX を使用してサーバーと通信しようとする前に、パスワードを入力する必要があります。
ブルートフォース攻撃から身を守る手段を組み込む必要があることに注意してください。したがって、間違ったパスワードが少数以上ある場合は、すべてをロックするなどのことを行ってください。
パスワードを使用して XHR の送信先を単純に復号化することも検討できますが、このルートを使用する場合は、オフラインでブルート フォース攻撃が可能になるため、これを非常に慎重に保存する必要があります。
編集
APIをロックダウンして、単一のアプリケーションのみが使用できるようにすることは、実用的でも技術的にも不可能であるため、使用しているアクセスソフトウェアに関係なく、APIを使用してユーザーを認証することだけを望んでいます. 法的にあなたの内線だけに制限する契約にユーザーに署名させることもできますが、これはほとんど強制力がなく、悪用者を追跡するのに時間を費やすことになると思います.
認証されていない人に API の場所さえ知られたくない場合は、帯域外メカニズムを使用して認証を実行できます。電話、電子メール、SMS、または単純に、ユーザーにパスワードまたはトークンを付与する別の API を使用します。 API へのリクエストに付随する必要があります。
この帯域外プロセス中に、認証されたセッションごとにのみ有効な一意の URI (API アクセス ポイント) をユーザーに付与することもできます ( https://api.totally-cool-extension.com/api/ijyeDvB5dYvSiWG97OLuTAoNWwbhuZ0 /など)。サーバーへのその他の URI へのリクエストは、まったく機能しません。ただし、これは理論的には、同じ API アクセス ポイントを使用し、適切なパスワードを使用することと大差ありません。認証および/または認可チェックを実行するアーキテクチャ内の場所の数を変更するだけです。
<aside>私の投票は、許可/認証ポイントの数をできるだけ少なくして、複数の場所やおそらく複数のロジックの欠陥やその他の脆弱性につながる可能性のあるものではなく、1 つの場所を正しくすることに多くの時間を費やすことができるようにすることです。</aside>
また、公開キー インフラストラクチャやワンタイム パスワード スキーム、またはデバイス ベースのトークン ジェネレーターなどを使用して調べることもできますが、最終的には、認証済みおよび承認済みのユーザーに API の使用を許可することになります。そして、インターネットのおかげで、これは長い間非公開の URI のままではありません。
さらに重要なことは、誰かが自分でデータを使用することを妨げるものではありません。これらすべての対策が講じられていても、許可されたユーザーが拡張機能にストリーミングされているときにこのデータを収集するのは簡単です. または、ポイントツーポイント暗号化を採用している場合、彼らはスクリーン スクラップを作成したり、コードそのものに対して何らかの形式の JS イントロスペクションを使用したり、コンピューターのメモリからデータを抽出したりすることさえできます。
ここで特効薬を探していたのは知っていますが、存在しません。