Springアプリケーションが、コントローラーやサービス内のブレークポイントに到達する前に403または401レスポンスを返す場合、問題は開発者が調査したいロジックではなく、リクエストの実行に先立つ認可層にある可能性があります。IntelliJ IDEAには、実行中のアプリケーションで実際に適用されている保護ルールを調査し、SecurityConfigを変更したりアプリケーションを再起動したりせずに、デバッグセッション中だけリクエストに一時的な認証情報と権限を付与する方法があります。
この機能はIntelliJ IDEA UltimateのSpring Debugger pluginの一部で、2026.2から利用できます。Security inlaysはデバッガーの実行中にデフォルトで表示され、アプリケーションがローカルで動作している場合でも、リモートJVM上で動作している場合でも使用できます。
まず、パスが実際に要求している内容を確認する
エディターまたはHTTPファイル内のインターフェースには、hasRoleやhasAuthorityに基づくルールを含め、エンドポイントに設定されたロールおよび権限ベースの要件が表示されます。ここでIntelliJ IDEAが依存するのは設定ファイルの読み取りだけではありません。Springコンテキストの初期化後、JVM内に実際に存在するSecurityFilterChainを調査します。複数のSecurityFilterChain、マッチャーの順序、有効なプロファイル、設定の条件付き登録が最終結果に影響する場合、これは重要です。
カスタムAuthorizationManagerの一部で発生するように、特定のルールをロールの一覧に変換できない場合、そのルールは不明な状態として表示され、関連する保護設定コードへのリンクが示されます。この場合、ロール一覧に基づく自動的な開放は利用できず、SecurityConfigを確認する必要があります。
デバッグセッション中にパスを一時的に開放する
Unlockアクションには2つのオプションがあります。1つ目は、パスに必要なロールのセットを持つ認証済みユーザーとしてリクエストを通過させる方法で、保護されたパスの背後にあるコントローラーまたはサービスのロジックをテストしたい場合に適しています。2つ目は、adminとROLE_ADMINおよびROLE_MANAGERのように、ユーザー名とカスタム権限の一覧を指定できる方法で、特定の権限セットの下でアプリケーションの動作をテストできます。
このアクションを実行すると、デバッガーは実行中のアプリケーション内のSecurityContextにTestingAuthenticationTokenオブジェクトを作成します。hasRoleとhasAuthorityのチェック、SecurityContextHolder.getContext().getAuthentication()、およびPrincipalまたはAuthentication型のパラメーターは、開発者が指定したIDと権限を認識します。このアクションはアプリケーションコードや設定ファイルを変更せず、アプリケーションを再起動すると、Spring Boot DevToolsによるプロセス内再起動を含め、開放状態は消えます。パスを手動でロックした場合も同様です。
影響はIntelliJ IDEAから送信されたリクエストに限定されません。特定のパスに対するGETを開放すると、curl、Postman、ブラウザーなど、同じURIとHTTPメソッドにアクセスするあらゆるクライアントに影響します。コントローラー定義でパスパターンを開放した場合、そのパターンに一致するすべての値が対象になる可能性があります。そのため、特にアプリケーションがネットワーク経由で利用可能な場合は、作業が終わり次第パスを再度ロックするか、デバッグセッションを終了する必要があります。
Unlockで回避できないもの
このアクションはSpring Security全体を無効にするものではなく、CSRF保護も回避しません。POST、PUT、DELETEなどのリクエストで有効なCSRFトークンが必要な場合、CsrfFilterは引き続きリクエストを拒否できます。また、対象範囲はServletスタック内のAuthorizationFilterによるエンドポイント認可に限られます。AuthorizationWebFilterを使用するSpring WebFluxはサポートされません。
@PreAuthorize、@PostAuthorize、@Securedなど、メソッドレベルの保護要件を表示または開放するための直接的なインターフェースもありません。ただし、SecurityContextに注入された権限は後続のメソッドセキュリティインターセプターから読み取れるため、付与された権限が条件を満たしていれば、@PreAuthorizeで保護されたサービス呼び出しが成功する可能性があります。これはIntelliJ IDEAがメソッド自体の保護を開放したことを意味するのではなく、チェックが同じ人工的な認証コンテキストを読み取ったということです。
IDの制約とテストツールとの統合
デバッガーが作成するIDは、TestingAuthenticationToken内の文字列ユーザー名であり、アプリケーション固有のUserDetailsや、ユーザーオブジェクトのカスタム型ではありません。そのため、@AuthenticationPrincipalを持つパラメーターがnullを返す場合があります。これは既知の問題で、番号はIDEA-389767です。本記事の公開時点では、2026.2でこの問題が発生していました。
パラメーターの型としてPrincipalまたはAuthenticationを使用できますが、JwtAuthenticationTokenのような具象型に依存すると、注入されたオブジェクトがその型ではないためIllegalStateExceptionが発生する可能性があります。また、claims、credentials、セッションに関連付けられたID、または特定の認証トークン型に依存する部分では、結果が異なったり失敗したりする場合があります。
開放は、組み込みの.httpファイル、curl、Postman、テストフレームワークから送信されるリクエストで機能します。ただし、パスを開放したのと同じ実行中のアプリケーションであることが条件です。自動化されたワークフローやAIエージェントに依存するワークフローでは、現在この操作を実行するプログラム用のキーはありません。JetBrainsは2026.3でMCPツールと、それに関連するスキルを追加する予定ですが、現行バージョンではIDE内で最初に手動クリックする必要があります。
なぜこの方法が重要なのか
ここでの実用的な価値は、保護を無効にすることではなく、別の環境に持ち込まれる可能性のある一時的な設定ファイルの変更を残さずに、開発者がテストしたいロジックから認可層を切り離すことにあります。一方で、この開放は実行中のプロセスに対する一時的なセキュリティ変更であり、IDEからのリクエストだけに限定されたローカルなシミュレーションではありません。そのため、使用前にパス、メソッド、影響を受けるクライアントを確認し、実際の認証テストの代替ではなく、範囲を慎重に管理したデバッグツールとして扱う必要があります。
また、この機能はパスを開放してもログにメッセージを記録せず、リモートアプリケーションでパスが開放されていることをActuator経由で示すインジケーターも提供しません。記事によれば、状態を確認できるのは、アプリケーションに接続されたIDE内のインターフェースだけです。必要がない場合は、IntelliJ IDEAのRegistryにあるspring.debugger.security.enabled設定でSecurity inlaysを無効にできます。