F12を押せば
全部見える

「5分でできる？チュートリアルどおりにしたら動いた？」

やってみてください。売上がなければ気付かず、廃業してそのまま終わるかもしれません。
売上が増え、標的になってから知ることになります。

なぜ怖いのか — 身近な2つの例

• iOSアプリ内課金 — かつてゲーム会社を苦しめた領域。Appleの30%手数料・自動更新・返金・レシート検証……
• 中小企業の顧客対応 — 決済事故では怒りが直撃します。「俺の金はどこへ行った」という暴言、星1つの評価が殺到し、1か月で評判が崩れます。

Networkタブに見えるもの

APIの呼出し先・リクエスト内容・レスポンス内容
使用中のAIモデル・環境変数・localStorage・Cookie
すべて公開状態です。

部屋の引き出しのたとえ

自分の部屋で日記を取り出すのは事故ではありません。
本当の事故は泥棒が窓を割って盗めるままに放置することです。

「泥棒」の正体はXSS攻撃者

ページに悪意あるJavaScriptが埋め込まれた状態（Cross-Site Scripting）。
localStorageは同一ドメインのJSからすべて読める→悪意あるスクリプトがトークンを盗む。
HttpOnly CookieはJSからそもそも見えない→盗めない。HttpOnlyの役目は、XSSが起きてもトークンを盗ませないこと。

問題 — 4つの基本防御がすべて欠如

創業者が「1行も書いていない」と自慢したB2BリードSaaS。
APIキーがフロントに露出、認証なし、DB無防備、レート制限なし。

攻撃経路

ブラウザーコンソールで決済を回避→有料機能を無料利用→APIキーの利用枠を消費。
Cursorで修正を試みる→「別の部分を壊し続けた」→断念して廃業。

事故の経緯 — 二重のミス

創業者Matt Schlichtが「1行も書いていない」と宣言したAIエージェントのSNS。
Supabaseを使用し、RLS無効＋権限付きキーがクライアントJSに露出。
→ anonキー自体は公開してよい。RLS無効とシークレットキー露出の組合せが事故の原因。

1回目の流出（2025年7月）

女性専用アプリ。登録時に運転免許証とセルフィーを収集。
Firebase Storageを誰でもアクセスできる権限のまま放置。
画像7.2万件が流出。運転免許証を含むセルフィー約1.3万件。

2回目の流出（数日後）

さらに個人メッセージ110万件が流出。
中絶の相談や不倫の悩みなど、極めて機微な会話も含まれていた。

場面①・動画の導入部 — ドキュメンタリーの主人公

セキュリティ系スタートアップCEO・バリ在住・1日30分勤務・エージェントの結果だけを承認

その人がそこに至るまで、推測するしかない4つのこと —

（参考までに、Palantir Enterpriseに月2千万ウォン以上払う会社もあります。）

場面②・28～32分

ホテル予約エージェントに「50万ウォンだけ使え」と指示した結果、76万ウォンに。

KAISTの研究者とKBSスタッフが作った管理下の攻撃実験。外部Webページに埋めた攻撃用コードとプロンプトでエージェントを誤作動させるシナリオです。実際の被害者ではありません。

講師の前職は雑誌記者（第1回に紹介）。メディアの見せ方は編集部の意図の結果です。

家で動画を見ながら2つ確認してください。
① CEOの努力・勉強・試行錯誤・費用は画面に出ていますか？
② 攻撃の仕組み（アテンション・ツール呼出し・判断・IDPI）は明確に説明されていますか？

出ていなければ編集で切られたもの。それがメディアの本質です。

たとえ

マンションの1階に100世帯分の郵便受けがあります。
「自分の郵便受けは自分だけが開けられる」のが正常。
→ RLS有効＝正常

有効にしなければ？

住民なら誰でも100世帯分の郵便受けを開けられる。
隣人の通帳、カード請求書、書留郵便まで読めます。
→ Supabase・FirebaseはデフォルトOFF。有効にしなければ誰でも全利用者のデータを読み書きできます。

たとえ（シークレットキーのみ）

ホテル従業員のマスターキーは全客室を開けられます。
OpenAI・Anthropic・AWSのシークレットキーも同じ。「このキーさえあれば、その会社のサービスを自由に使える」
→ 利用料はキーの持ち主である自分に請求。公開キーは別種です。S10の分類を参照。

コードに埋め込むと？

ホテルの正面玄関にマスターキーを鍵もかけず掛けておく状態。
通行人が外して全客室を開け、ミニバーや金庫を荒らせます。
→ GitHubにキーが上がると30分以内にボットが収集→OpenAIの請求が急増し、1か月で数千万～数億ウォン。

公開キーには付けてよい

Firebase apiKey、Stripe pk_*、Supabase anonなどの公開キーにはNEXT_PUBLIC_*・VITE_*を付けてよいです。もともと公開を想定したキーだからです。
→ シークレットキーには絶対に付けない。S10参照。

たとえ

店には2種類の文字があります。
看板は通行人も読める（電話番号・住所・メニュー）。
店主の金庫の中は従業員も見られない（現金・印鑑・通帳）。
→ NEXT_PUBLIC_付きのキーは看板の文字。ビルド時にそのままブラウザーへ出ます。

誤ってシークレットキーに付けたら？

金庫の暗証番号を看板に書くようなもの。
OpenAI sk-*・Supabase service_roleなどのシークレットキーにNEXT_PUBLIC_を付けると、F12一発で泥棒の手に。
→ VITE_・REACT_APP_も同じ原理。他のフレームワークにも同じ罠。

よくある混同：「FirebaseはInfo.plistにキーを入れるように言っていたけど？」

そのとおり。FirebaseのapiKeyは公開キーで、それ自体に権限はありません。だからアプリに入れてよいのです。
本当の防御はFirebase Security Rules＋App Check。Google Mapsキー・Stripe `pk_*`・Supabase `anon`も同様です。

→ S10の公開キーとシークレットキーの表を思い出してください。シークレットはバックエンド、公開キーはアプリでよいがポリシーの有効化は必須。

たとえ — 飲食店

客＝利用者（ブラウザー）
従業員＝自分のサーバー（BFF・Backend For Frontend）
店主＝外部API（OpenAI・銀行・決済）
→ 客が店主の事務所に入り金庫に触れてはいけません。従業員が客の依頼を店主に伝えます。

客が店主に直接会うと？

客が金庫の暗証番号（APIキー）を知ってしまいます。
その客は別の客のふりをして毎日来店し、金庫を荒らします。
→ クライアントからOpenAI・銀行を直接呼ぶとAPIキーが露出。ボットが収集して請求が急増します。

Source Mapとは？

自分のコード（TS・JSX・最新JS）→ビルドツールが圧縮・変換・1つにまとめる4段階の処理→ブラウザーへ送ります。変換後のコードは人には読めません。

デバッグのため、ビルドが原本と圧縮版の対応表を別途作ります。それが.mapファイル、Source Mapです。

たとえ：韓国語の本の英訳版に付く対照表。英訳に誤字があったとき、原文のどこかを探す辞書です。

Source Mapが公開される場合

自分のプロジェクトで原本コード・コメント・主要ロジックが公開されていないか確認してください。

2つの選択肢

① 完全に無効化（`sourcemap: false`）：最も安全ですが、本番エラーの追跡は難しくなります。
② hidden-source-map：生成はするがsourceMappingURLコメントを付けない。一般利用者のF12には見えません。

hidden-source-mapの仕組み

生成された.mapをサーバー配信に含めず、Sentry・Datadogなどのエラー追跡サービスへ別途アップロード。
→ 本番エラーをSentryの画面で原本の行まで追跡できますが、F12からは見えません。

フレームワーク別の設定

Next.js — productionBrowserSourceMaps: false＋Sentry連携
Vite — build.sourcemap: 'hidden'
Webpack — devtool: 'hidden-source-map'
CRA — GENERATE_SOURCEMAP=false（CRAはhidden非対応）

たとえ

完成した建物を外から見るだけでは、換気口・秘密通路・金庫の場所は分かりません。
設計図があれば、どこに何があるか分かります。
→ Source Mapは圧縮コードと原本の対応表。あればF12で原本が見えます。

設計図を外部に公開すると？

泥棒が建物中の換気口・秘密通路・金庫の場所を知ります。
外観は同じでも侵入経路が無数になります。
→ 本番で.mapを公開すると業務ロジック・安全性の検証コード・コメントがすべて見え、弱点がすぐ見つかります。

たとえ

Git＝日記の自動バックアップ（毎日写真を撮りクラウドに保存）
.env＝秘密の日記（パスワード・口座の暗証番号・誰かの悪口）
.gitignore＝「これはバックアップしない」一覧
→ Gitは全ファイルを自動でクラウドへ上げます。秘密の日記は.gitignoreに書いておかないと上がってしまいます。

.gitignoreに書かなければ？

秘密の日記までクラウドに自動保存されます。しかも履歴に永久に残ります。一度上がったパスワードはすぐキーを再発行。
→ GitHubに.envを誤コミットすると30分以内にボットがキーを収集。AWS・OpenAIの請求が急増。あとから削除しても履歴に残ります。

講師の実体験

Claudeに「これを記録しておいて」と指示。
「はい、記録しました」と返答。
次のセッションで聞くと知らない。実際は記録していないことが頻繁にあります。

さらにひどい場合

ひどいと同じセッション内でも2時間前の話を覚えていません。
→ コンテキストが長いほど前半が曖昧になります。第3回のContext Rotそのものです。

account.md（.gitignoreに追加）

キーの発行元・クラウドのアカウントメール・インフラ設定値・コンテナー名
パスワードは絶対に入れない

規則が増えたら別ファイルへ

セキュリティ規則が長くなったらSECURITY.mdに移し、CLAUDE.mdには参照だけを置いてもよいです。
→ 第3回の正本と参照のパターン。CLAUDE.mdは短く、詳細は別ファイルへ。

これで終わりではありません

Webとバックエンドが守るべき項目は膨大です。
この6つは出発点。OWASP Top 10・トークン保存場所・CSP・CORS・Rate Limit・SQL Injection・CSRF・SSRF・Race Conditionと際限なく続きます。
→ 今日の6つはバイブコーダーが最もよく忘れる項目です。

① 認証トークン：localStorageに保存

キーは*_token、JWT形式、120文字。
→ 第4回の中心的なアンチパターン。F12一発で誰でもトークンを確認できます。

② トークンをデコード：有効期間24時間

HS256、payloadはsubとexpのみ（iat・jti・iss・audなし）、24時間後に失効。
→ 標準的なaccessは15分～1時間。24時間＋jtiなしは盗難時に強制失効できず24時間使い放題。

③ セキュリティレスポンスヘッダー：5つ欠落

CSP・X-Frame-Options・X-Content-Type-Options・Referrer-Policy・Permissions-Policyがすべてなし。
→ HSTSだけ有効。CSPが1行あればXSSのインラインスクリプトを止められたはずですが、防御層ゼロ。

④ 多数の外部サービス＋CSPなし＝供給網攻撃の範囲が拡大

GTM・GA・複数の外部CDNを読み込み。CSPがないため、そのドメインが侵害されるとサイトの全利用者へ悪意あるコードが広がり得ます。

① トークンをlocalStorageに置くことだけなら議論の余地がある

トークンの保存場所とCSP・XSS対策を一緒に検討する必要があります。

② 組合せ（localStorage＋CSPなし＋24h＋jtiなし） — 一緒に確認する項目

CSP・トークンの有効期限・再利用防止を一緒に確認する必要があります。

③ 一言で

localStorageに危険な値（認証・決済・個人識別情報）は絶対に置かない。
ダークモード・言語・UI状態はよい。機密は不可。

④ このサービスは

後者の②の組合せに近い。
localStorageだけを見て批判しているのではなく、組合せが危険です。

1つ目：できないのではなく、やっていない

Vite＋React＋Vercelできれいに作った人たちです。頭のよい人たちです。
認証トークンをHttpOnly Cookieに入れる5分の作業をしていなかった。

2つ目：1兆ウォン企業もやっていない

EnrichLead・Moltbook・Teaはすべて決済を受けていた会社です。
最低限も押さえず、1度の事故で1週間で廃業（EnrichLead）。

3つ目：皆さんも同じ脅威の中にいる

バイブコーディングで決済を付け、利用者を受け入れた瞬間、F12一発ですべて見えます。

最後に一言

私の指示は韓国語で「セキュリティ監査して」の一言でした。
Claudeはその一言でここまで見つけました。

では攻撃に長けた人が同じサイトを狙ったらどうなるでしょう？

27年前の言葉です。

第1回の話：「本だ／専門家を見下すな／Anthropicも本で学んだ」
この人がその例。ソフトウェア業界の神です。

もちろんダイクストラ法のDijkstraやリスコフの置換原則のLiskovもいます。
正確には理論の神ではなく企業向け開発実務の神。
分野は違いますが、千年前からコーディングを学んでも追い付けない神です。

2023～2025年 — 今も現役

martinfowler.comでExploring Generative AIシリーズを公開中。
27年前の本の著者が、AI時代のコーディングについても書き続けています。

つまり皆さんのClaudeも、この人の文章を学習しているはずです。

コードより単純。誰でもできます。

画像生成AIでイラスト・風景画・油絵・水彩画を全部試す。

講師の例：Geminiアプリ初登場から100枚以上を調整。所属するバイク仲間のエンブレムも自作。