RSC/Next.jsは信頼できないかもだけど、それで良いのかもしれない

背景

先日、RSCに重大な脆弱性が見つかりました。詳細については多くの記事が書かれていますので割愛しますが、Next.jsをただデプロイしているだけでもやられる重大さです。

RSCの設計自体も問題視されています。当初からセキュリティの議論が多く、今回の件とは直接関係がないものの、サーバとクライアントの境界が曖昧な点などが指摘されていました。この状況を見ていると最悪の場合、RSC/Next.jsのセキュリティを十分に高めることが現実的に不可能となる可能性も残されており、今後注視する必要があります。

でも本当にNext.jsってセキュリティが重要なのだろうか？ サーバはセキュアでなければならないと我々はずっと学んできましたが、これが先入観である可能性もあります。

私たちが日常的にウェブサイトを作るとき、「ブラウザからのデータは絶対に信用するな！」って教わります。ブラウザ等のHTTPクライアントを、私たちは基本的には信用しません。ということは、ウェブサイトが表示されるまでの流れの中で、途中に信用できないものがあっても対応可能なのです。

本記事では 「サーバはセキュアでなければならない」というのは先入観だという視点に立ち、Next.jsをBFFとして使う場合はセキュアでなくても良い可能性を探ります。RSC/Next.jsのBFFはあくまでもブラウザの拡張であると捉え、BFFを信用しないアーキテクチャを考えます。

Next.jsのBFFを信頼できないものとして考える

Next.jsサーバを信頼した構成

ここではNext.jsサーバを信頼した構成の代表として、完全フルスタックのものについて話をします。この構成だとNext.jsは直接DBにアクセスをしますし、外部サービスにアクセスするための長期クレデンシャルも読めないといけません。

この場合はNext.jsに侵入されるとDBにアクセスされてしまいますし、外部サービスに自由にアクセスするための長期クレデンシャルも盗まれてしまいます。甚大な被害になる可能性が高いです。

Next.jsサーバを信頼しない構成

ここではNext.jsをBFFとし、Ruby on RailsをAPIサーバとした構成の話をします。 DBアクセスはAPIサーバだけが行います。また外部サービスにアクセスするための長期クレデンシャルはNext.js BFFからは読まず、APIサーバだけが長期クレデンシャルを読むようにします。

この場合、攻撃者はNext.js BFFに侵入できてもAPIサーバには侵入できず、DBにアクセスできません。外部サービスの長期クレデンシャルも盗めません。既存データは被害を受けませんので、影響範囲は限定的になります。

この構成の特徴はNext.js BFFを一切信用していないことです。ブラウザに対する一般的な姿勢と同じです。つまりNext.js BFFはあくまでもブラウザの一部であり、ハード的にはサーバではあるもののセキュリティ的にはサーバ扱いしないのです。

Next.jsを信頼しない方が他のフロントエンド技術と共存しやすい

Next.jsを信頼しない構成はセキュリティだけではなく、実は他の面でも好都合です。特に複数のフロントエンド技術が使われているプロダクトではメリットがあります。

長期間運用されている製品は、複数のフロントエンド技術を使用していることが一般的です。例えば下記のものを組み合わせていることが珍しくありません。

• Rails ERB (+ jQuery)
• React SPA
  • クラスコンポーネントを使うもの、Reduxを使うもの、あるいはNext.jsだがSPAとして使用しているものなど、React SPAだけでも複数のタイプが存在することがあります
• React SSR/RSC (Next.js)

フロントエンド技術が多数存在しても、ユーザが技術の境目を意識することなくサイトをスムーズに使えることは必須です。そのため、SSR/RSCを使ったNext.jsのことだけではなく、その他の技術との共存も考える必要があります。

このケースではNext.js BFFを信頼しない設計が適しています。Rails ERBやReact SPAも信頼されておらず、Next.js BFFも信頼しない方が一貫性があるためです。

このケースではセキュリティ問題を抜きに考えても、Next.js BFFを信頼しない設計の方が良いのです。

認証の視点で信頼しない設計のメリットを考える

Next.js BFFを信頼しない設計の方が適切であることを、もう少し具体的に考えます。認証の例で考えます。

• Next.jsを信頼する設計の場合: Next.jsに対してブラウザがcookie認証をします
  • 例えばNextAuthがよく使用されます
  • Next.jsはパスワードの確認等のためにDBや外部サービスにアクセス用のSECRETを持ちます
  • 他のSPA/ERBの認証とは異なる仕組みを使用するため、cookieの互換性がありません。これが原因で認証の共通化に苦労するケースがあります
• Next.jsを信頼しない設計の場合: Railsに対してNext.jsがcookie認証をします
  • Next.jsはcookieをそのままブラウザにリレーします。Next.jsは中継するだけですので、SECRET等を持ちません。認証はあくまでもRuby on RailsのAPIサーバが担います。
  • BFFがリレーする点を除けば、SPA/ERBの認証と全く同じになります。Cookieもそのまま共通で使用でき、シームレスに認証を共通化できます

Next.jsを信頼しない方がフロントエンドエンジニアは楽

Next.jsのBFFは一般にフロントエンドエンジニアが管理します。AWSを使う場合は大変ですが、もちろんVercelなどを使うとかなり楽になります。

しかし大変なのはサーバの管理だけではありません。認証・認可、CSRF等々もサーバサイドコードを書く際に重要です。クレデンシャルなどの機密情報の管理にも配慮が必要です。Next.js BFFは信頼できないと決めてしまえば、フロントエンドエンジニアはこのようなことに頭を悩ませないで済みます。

それで何が言いたいの？

今回のRSC脆弱性の問題をきっかけに、Next.jsの役割を振り返り、最も適切なNext.jsの使い方を確認すると良いのではないかと思います。前から言われていたことではあるのですが、セキュリティ面ではNext.jsに不安があるからです。

数年前はNext.jsがフルスタックフレームワークとしてRailsを代替しいくのではないかと言われたことがあり、またクラウドDB等の登場により、サーバレス環境で動作するNext.jsもRDMSに直接接続できるようにもなりました。しかしNext.jsの強みはそこではなく、あくまでもフロントエンドのUI/UX及びDXを改善することに軸足があります。Next.js/Reactの近年のアップデートもRSC/Streamingやキャッシュ周りが主で、バックエンドを強化するものではありません。これはReactの歴史を考えれば当然のことです。

大型システムのフロントエンドでNext.jsを使用している場合は、もともとNext.js BFFを信頼しない構成になっているものが多いはずです。そして小規模で短命のアプリならNext.jsを信頼して完全フルスタックにしても良いでしょう。

ただし長期間運用し、機密性の高い情報を載せ、多くの機能を追加していくようなシステムの場合はNext.jsのフルスタックは適していないと考えた方が良さそうです。

RSCに重大な脆弱性が見つかったからNext.jsの使用を諦めるのではなく、ネットに落ちているフルスタックNext.jsの記事等に惑わされず、自分の用途に合わせた適切な使い方をすれば良いだけのことだと思います。