Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Server側でStateを使用した時の情報漏洩の危険性を見てみる
Search
Yuki Ishii
November 08, 2024
Programming
1
84
Server側でStateを使用した時の情報漏洩の危険性を見てみる
SvelteKit で Shared State を server側で使用するときは気をつけましょう。
個人情報の漏洩につながる可能性があります。
Yuki Ishii
November 08, 2024
Tweet
Share
More Decks by Yuki Ishii
See All by Yuki Ishii
Rustのweb開発を助ける 便利なツール紹介
yuki0418
1
410
Other Decks in Programming
See All in Programming
ファインディLT_ポケモン対戦の定量的分析
fufufukakaka
0
950
1年目の私に伝えたい!テストコードを怖がらなくなるためのヒント/Tips for not being afraid of test code
push_gawa
1
650
コミュニティ駆動 AWS CDK ライブラリ「Open Constructs Library」 / community-cdk-library
gotok365
2
260
仕様変更に耐えるための"今の"DRY原則を考える
mkmk884
9
3.3k
color-scheme: light dark; を完全に理解する
uhyo
7
510
Boost Your Web Performance with Hyperdrive
chimame
1
100
新宿駅構内を三人称視点で探索してみる
satoshi7190
2
130
Rails 1.0 のコードで学ぶ find_by* と method_missing の仕組み / Learn how find_by_* and method_missing work in Rails 1.0 code
maimux2x
1
260
AWS Step Functions は CDK で書こう!
konokenj
5
890
PEPCは何を変えようとしていたのか
ken7253
3
310
責務と認知負荷を整える! 抽象レベルを意識した関心の分離
yahiru
9
1.5k
自力でTTSモデルを作った話
zgock999
0
120
Featured
See All Featured
Rebuilding a faster, lazier Slack
samanthasiow
80
8.9k
Building Flexible Design Systems
yeseniaperezcruz
328
38k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
30
4.6k
Producing Creativity
orderedlist
PRO
344
40k
Agile that works and the tools we love
rasmusluckow
328
21k
4 Signs Your Business is Dying
shpigford
183
22k
GraphQLとの向き合い方2022年版
quramy
44
14k
KATA
mclloyd
29
14k
StorybookのUI Testing Handbookを読んだ
zakiyama
28
5.5k
The Cost Of JavaScript in 2023
addyosmani
47
7.5k
Building a Scalable Design System with Sketch
lauravandoore
461
33k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
33
2.1k
Transcript
Server側でStateを使用した時の 情報漏洩の危険性を見てみる Yuki Ishii (いっしー)
Memo - 自己紹介 1min - 目的紹介 1min - State management
について 1min - Avoid shared state on the server について 2min - 実技 4min - Conclusion 1min
自己紹介
自己紹介 - 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 してます
目的
今回の登壇の背景・目的 SvelteKit のドキュメントに下記のように記載されてます。
今回の登壇の背景・目的 - 理屈がわかったので実際に体験してみたい - 初学者などは気をつけないといけないため - せっかくだから Runes $state を使ってみる
- (svelte/store から writable もあるが)
Rune について
Runeとは Svelte 5 で導入された Svelte compiler をコントロールするための Keyword です。 ‘$’
から始まる関数となります。 今回は $state を使用して reactive state を管理していきます。 React の useState() に似たものです。
Shared State の仕組み
Shared State の仕組み $state などは memory 上に ‘count’ 変数 を作成します。
Shared State の仕組み - Browserの場合 Client側の場合は Browser上のメモリに変数が作成されるので他のユーザーとは共有 しません。
Shared State の仕組み - Serverの場合 Server側の場合、同じサーバーのメモリにアクセスされるので変数が共有されてしまう。 基本 Server は Long
life なので 変数が生き続けている。 個人情報などが漏れてしまう。
実際にみてみましょう
要件 - Integer を保存しておく Counter Store を作成します。 - Counter Store
は increment と decrement 関数を保有して Integer を操作しま す。 - Client側 (+page.svelte) と Server側 (+page.server.ts) で使用して 比較してみます。 - import { writable } from 'svelte/store' があるが、今回は $state を使用していき ます。
+page.svlte で使用した場合 +page.svelte 側で $state をする場合はブラウザー上のメモリに変数が作成されます。
+page.server.svelte で使用した場合 SvelteKit server 上のメモリに変数が作成されます。複数のユーザー同じリファレンスの 変数を操作するので、値が共有されてしまいます。
まとめ - Shared State (storeなど)はサーバー側では使わないようにしましょう。 - Context API と併用で対策は可能です。
ご清聴ありがとうございました