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
110
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
480
Other Decks in Programming
See All in Programming
AIでLINEスタンプを作ってみた
eycjur
1
230
Vue・React マルチプロダクト開発を支える Vite
andpad
0
110
Reading Rails 1.0 Source Code
okuramasafumi
0
230
Performance for Conversion! 分散トレーシングでボトルネックを 特定せよ
inetand
0
860
FindyにおけるTakumi活用と脆弱性管理のこれから
rvirus0817
0
510
さようなら Date。 ようこそTemporal! 3年間先行利用して得られた知見の共有
8beeeaaat
3
1.4k
Design Foundational Data Engineering Observability
sucitw
3
200
概念モデル→論理モデルで気をつけていること
sunnyone
2
230
Ruby Parser progress report 2025
yui_knk
1
440
How Android Uses Data Structures Behind The Scenes
l2hyunwoo
0
460
モバイルアプリからWebへの横展開を加速した話_Claude_Code_実践術.pdf
kazuyasakamoto
0
330
AWS発のAIエディタKiroを使ってみた
iriikeita
1
190
Featured
See All Featured
How to Think Like a Performance Engineer
csswizardry
26
1.9k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.4k
Facilitating Awesome Meetings
lara
55
6.5k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
131
19k
The Art of Programming - Codeland 2020
erikaheidi
56
13k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
656
61k
RailsConf 2023
tenderlove
30
1.2k
The Cult of Friendly URLs
andyhume
79
6.6k
What’s in a name? Adding method to the madness
productmarketing
PRO
23
3.7k
We Have a Design System, Now What?
morganepeng
53
7.8k
Building Applications with DynamoDB
mza
96
6.6k
Art, The Web, and Tiny UX
lynnandtonic
303
21k
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 と併用で対策は可能です。
ご清聴ありがとうございました