Railsのprotect_from_forgeryで生成されるauthenticity_tokenの信ぴょう性

Question

ひょんなことからRailsのアプリを触る機会があり、Railsデフォルトで用意されているCSRF対策について調査しています。

Railsではデフォルトでapplication_controller内にprotect_from_forgery with: :exceptionの記述があります。

これにより、POST、PUTの際にヘルパーが自動的にauthenticity_tokenを生成（もしくはヘッダーに付与）し、セッション変数と照らし合わせることによりCSRFの対策をしているようです。

しかしながら、実際の挙動を確認したところ、

一度生成されたauthenticity_tokenは使いまわしが可能

という挙動になっていました。

authenticity_tokenは通常にサイト内回遊すると、毎回別のトークンが生成されますが、「必ずしもそこで生成されたトークンである必要はない」ということです。（前ページで生成されたトークンも使用可能）
※もちろん別セッションとなった場合の使い回しは不可能

これってCSRF対策として十分なんでしょうか？仮にauthenticity_tokenの値を知り得てしまった場合、セッションが消えるまではそのトークンを用いることでリクエスト自体は通ってしまうため、ちょっと微妙なのでは、、、？と思ってます。

この辺りの挙動/あるべき姿に詳しい方からのご教示をお待ちしています。

Answer 1

別のセッションで生成されたトークンが有効なら問題ですが、ご指摘の状態は問題ありません。というか、そうあるべきものです。
というのは、複数タブで同じアプリケーションを開いていると、まさに「前ページで生成されたトークン」が使われる状況はあり得るからです。
逆に最新のトークンのみ有効にしてしまうと、複数タブが開いている状況などで、正当なリクエストがブロックされる原因になります。