Server側でStateを使用した時の情報漏洩の危険性を見てみる

SvelteKit で Shared State を server側で使用するときは気をつけましょう。
個人情報の漏洩につながる可能性があります。

Transcript

1. Server側でStateを使用した時の 情報漏洩の危険性を見てみる Yuki Ishii (いっしー)
2. Memo - 自己紹介 1min - 目的紹介 1min - State management について 1min - Avoid shared state on the server について 2min - 実技 4min - Conclusion 1min
3. 自己紹介
4. 自己紹介 - Yuki Ishii (いっしー) ポジション : Full-Stack Developer 経歴: ex-CyberAgent 有限会社トップ・スペース はこぶね便事務局 (現 ひとりエンジニア) 使用言語: Rust, Svelte X: @Yuki_Ishii_Dev Bsky: @yuki-ishii Blog: https://blog.yuki-dev.com/ 今年から Rust.tokyo の Organizer してます
5. 目的
6. 今回の登壇の背景・目的 SvelteKit のドキュメントに下記のように記載されてます。
7. 今回の登壇の背景・目的 - 理屈がわかったので実際に体験してみたい - 初学者などは気をつけないといけないため - せっかくだから Runes $state を使ってみる - (svelte/store から writable もあるが)
8. Rune について
9. Runeとは Svelte 5 で導入された Svelte compiler をコントロールするための Keyword です。 ‘$’ から始まる関数となります。 今回は $state を使用して reactive state を管理していきます。 React の useState() に似たものです。
10. Shared State の仕組み
11. Shared State の仕組み $state などは memory 上に ‘count’ 変数 を作成します。
12. Shared State の仕組み - Browserの場合 Client側の場合は Browser上のメモリに変数が作成されるので他のユーザーとは共有 しません。
13. Shared State の仕組み - Serverの場合 Server側の場合、同じサーバーのメモリにアクセスされるので変数が共有されてしまう。 基本 Server は Long life なので 変数が生き続けている。 個人情報などが漏れてしまう。
14. 実際にみてみましょう
15. 要件 - Integer を保存しておく Counter Store を作成します。 - Counter Store は increment と decrement 関数を保有して Integer を操作しま す。 - Client側 (+page.svelte) と Server側 (+page.server.ts) で使用して 比較してみます。 - import { writable } from 'svelte/store' があるが、今回は $state を使用していき ます。
16. +page.svlte で使用した場合 +page.svelte 側で $state をする場合はブラウザー上のメモリに変数が作成されます。
17. +page.server.svelte で使用した場合 SvelteKit server 上のメモリに変数が作成されます。複数のユーザー同じリファレンスの 変数を操作するので、値が共有されてしまいます。
18. まとめ - Shared State (storeなど)はサーバー側では使わないようにしましょう。 - Context API と併用で対策は可能です。
19. ご清聴ありがとうございました