1つのボタンを含むWebサイトがあるとします。
このボタンを押すと、ajaxリクエストがサーバーに送信されます。サーバーはリクエストを受信し、データベースの内部カウンターに1を追加します。
ユーザーは、リクエスト全体（およびそのヘッダー）をコピーし、サーバーに過負荷をかける（そしてカウンターを混乱させる）無限のリクエストを送信するスクリプトを作成できます。
私は避けようとしています：
バックエンドでphpを使用しています。この状況を防ぐ方法はありますか？「見えない」リクエストを送信する方法はありますか？
ボタンに割り当てられ、ボタンを押すだけで1回だけ送信できる一意のトークンを作成できます。
これは、ユーザーが新しいボタンを取得するためにページを更新する必要があることを意味します。それが問題である場合は、トークンをボタンではなくユーザーに関連付けます。
上記の方法は、サーバー側のコードを追加する必要があることを意味します。エバークッキーのようなものを使用してクライアント側のボタン押下をログに記録し、ユーザーが別のリクエストを送信してユーザーから別のリクエストを受信するのを防ぐことができるかもしれません-私はこれをprodで行うことをお勧めしませんが、それは楽しいかもしれません;）
病気はもう少し明確にしようとします：
ボタンを生成して、そのボタン用に事前に生成されたuuidを含む「uuid」という非表示フィールドを含むフォームを送信するようにします。このuuidは、データベースまたはメモリに保持する必要があります。適切なuuidlibを使用する場合、ユーザーが既存のuuidを生成する可能性はごくわずかです。
ここで、ユーザーがボタンをクリックすると、アクションは/ my-button /？uuid=3394b0e0-a3bb-11e1-b3dd-0800200c9a66に移動します。
これで、サーバーはuuidが以前に生成されたものであるかどうかを確認します。そうである場合は、格納されている場所からuuidを削除し、アクションに何でも実行させます。uuidが存在しない場合、404を返します。
あなたの問題は「クロスサイトリクエストフォージェリ」と呼ばれています。
この問題を解決する良い方法は、ボタンのあるページが呼び出されたときにランダムな文字列を生成し、それをユーザーセッションと生成されたページに書き込み、ボタンを押したときに一緒に送信することです（たとえば、GETでリクエスト）。
バックエンド側では、送信された文字列がユーザーセッションの文字列と一致するかどうかを確認してから、セッションから文字列を削除します。両方の文字列が一致し、空ではなかった場合にのみ続行します。
このように、すべてのリクエストURLは1回だけ有効であり、ボタンが付いたページを最初に開いたユーザーに対してのみ有効です。
リクエストがどのように開始されるかを知ることはできません。できることは、偽造をより困難にすることだけです。しかし、これがセキュリティと関係がある場合、あなたが最も注意する必要があるのは、要求をうまく偽造できる人々です。したがって、これをある種のセキュリティ対策として試みることは、おそらく役に立たない（または誤解を招く）可能性があります。
サーバーが特定の時間内に1回だけ受け入れる暗号化されたキーを試すことができますが、それでも要求がどのように開始されたかはわかりません（実際にはそれに依存するべきではありません）。ボタンはUI機能であり、ユーザーエージェントがユーザーに提示するように構成されているものに基づいて他のUIアーティファクトに変換される可能性があります（ユーザーが関与している場合）。