これは誰のためのもの？
AIでアプリを作り、これから公開しようとしているすべての人へ——プログラミングの知識は不要。もしあなたのアプリがユーザーのデータ（アカウント、メッセージ、注文など何でも）を保存するなら、ネットに出す前にこれは必須だ。各セクションには例え、リスク、そしてAIに設定させるためのプロンプトが付いている。あなたは承認するだけでいい。
いつやるの？（正確なタイミング）
タイミングは明確で、譲れない：アプリを公開する、または実際のユーザーに渡す直前だ。 自分のパソコンで一人でテストしている間は何も起きない。だが、アプリが他人のデータを持ってネット上に出た瞬間、これらの鍵がなければすべてを晒すことになる。そしてAIは自分からはやってくれない（動かすことを考えていて、守ることは考えていない）ので、あなたが明示的に頼む必要がある。
このガイドが生まれた痛み
AIで作る人にとって最悪の恐怖だ：アプリを公開する、誰かがURLの数字を1つ変える……そして他のユーザーのデータを目にする。あるいはもっと悪い：セキュリティの穴からデータベース全体が晒される。作っているときには気づかない——すべて「動いている」——が、これは時限爆弾だ。この3つの鍵が数分でそれを解除する。
鍵その1 · RLS（各自が自分のものだけを見る）
こう想像してみて
みんなが自分のものをしまう巨大なおもちゃ箱を想像してほしい。鍵がなければ、誰でも全員のものを取り出せる。RLS（Row-Level Security、「行レベルセキュリティ」）は、誰が誰なのかを知っている魔法の鍵だ：全部が同じ箱に入っていても、各ユーザーは自分のデータだけを見て、触ることができる。
RLSがなければ、悪意あるユーザーはURLやリクエストのIDを1つ変えるだけで他人のデータを見られる。SupabaseやPostgreSQLを使うアプリで最もよくある脆弱性であり、最も簡単に悪用される。だからこれが鍵その1だ。
SupabaseをPostgreSQLで使っています。次のテーブルがあります：[あなたのテーブルとユーザー列を列挙、例：posts (user_id)、comments (post_id, user_id)]。 各ユーザーが自分のレコードだけを閲覧/編集/削除できるようにRow-Level Securityを設定してください。Supabaseの公式ベストプラクティスに従ってください： - すべてのテーブルでRLSを有効化する（ENABLE ROW LEVEL SECURITY）。 - SELECT、INSERT、UPDATE、DELETEごとに**別々の**ポリシーを作成する（FOR ALLは使わない）。 - パフォーマンスのために重要：ユーザー関数を (SELECT auth.uid()) のようにラップし、auth.uid() を裸で使わないこと。こうするとPostgresがクエリごとに1回だけ評価し、行ごとに評価しなくなります。 - ポリシーを authenticated ロールに限定する（TO authenticated）。public にはしない。匿名の訪問者がテーブルに触れられないようにするためです。 - ポリシーで user_metadata を**絶対に**使わない（ユーザーが改変できるため）。 - ポリシーで使う列（例：user_id）にインデックスを追加する。 - 忘れずに：UPDATE を機能させるには、SELECT のポリシーも必要です。 - SupabaseのSQL Editorにそのまま貼り付けられる完全なSQLをください。そして各ポリシーが何をするかを1行で説明してください。
アプリを激遅にする失敗（「init-plan trap」）
ほとんどのチュートリアルは、ポリシーで
auth.uid() を直接使うよう教える。だがそれだとPostgresが行ごとに1回ずつ評価してしまう——10万行のテーブルでは、5ミリ秒のクエリと5秒のクエリの差になる！ 裏ワザ（Supabaseが文書化している）：`(SELECT auth.uid())` と書くこと。こうすれば1回だけ評価される。だから上のプロンプトはこれを明示的に求めている。ちゃんと動いているか、どう確かめる？
- アプリでテスト用ユーザーを2人作る。
- ユーザーAでログインしてレコードを1つ作る。
- ユーザーBでログインする：Aのレコードが見えてはいけない。
- SupabaseのSecurity Advisorを確認する：RLSを付け忘れたテーブルがあれば教えてくれる。
鍵その2 · CORS（誰があなたのAPIを呼べるか）
こう想像してみて
CORSはあなたのAPIの門番だ。どのウェブページにドアをノックする許可があるかを決める。門番がいなければ、世界中のどんなサイトも、あなたのユーザーのブラウザからバックエンドを呼び出し、そのセッションを悪用できる。
私の本番ドメイン（https://mi-app.com）と開発時の localhost だけがリクエストできるように、バックエンドのCORSを設定してください。 - 本番環境では許可オリジンに "*" を使わないこと。 - 実際に使うメソッド（例：GET、POST、PUT、DELETE）だけを許可する。 - 必要なヘッダーだけを許可する。 - 私のスタックに合わせて、それぞれをどこに置くか正確に説明してください：[あなたのフレームワーク/バックエンドを伝える]。
絶対にやってはいけない失敗
認証情報（credentials）を有効にしたまま
Access-Control-Allow-Origin: * を残すこと。ドアを開けっ放しにして「どうぞ、鍵は中に置いておきました」という看板を出すようなものだ。もしAIが「早く動かすため」にそう設定していたら、公開前に直そう。鍵その3 · Security Headers（ブラウザへの防御指示）
こう想像してみて
セキュリティヘッダーは、入ってくるブラウザに対してサイトが伝えるこの家のルールだ：「別のサイトのフレームに私を埋め込むな」「私が許可していないサイトのスクリプトを読み込むな」「安全な接続でだけ私と話せ」。このルールがなければ、ブラウザは何でもやってしまう——そしてそれがよくある攻撃の入り口を開く。
推奨されるセキュリティヘッダーを私のアプリに追加してください：Content-Security-Policy、X-Frame-Options、X-Content-Type-Options、Referrer-Policy、Strict-Transport-Security（HSTS）、Permissions-Policy。 - それぞれが何をするかを簡単な1行で説明してください。 - 私のフレームワークにそのまま使える設定をください：[使っているものを伝える、例：Next.js、Express]。 - Content-Security-Policy は何も壊さないように report-only モードで始めて、その後どう厳しくするか教えてください。 - 結果をどう検証するか教えてください。
評価を無料でチェック
設定したら、あなたのサイトのURLをsecurityheaders.comに貼り付けると、A+からFまでの評価をくれる。ちゃんと設定できたか最速で確認できる方法だ——Aを目指そう。
習慣 · 公開のたびに見直す
公開前セキュリティチェックリスト
- ユーザーデータを持つすべてのテーブルでRLS有効化（2アカウントでテスト済み）。
- CORSは自分のドメインに限定、認証情報付きで
*は絶対にしない。 - ヘッダーを設定し、securityheaders.com で評価A。
- 秘密情報（.env、APIキー）を絶対にGitHubに上げていない（シリーズのGitHubガイド参照）。
- SupabaseのSecurity Advisorを確認し、赤い警告が残っていない。
C-A-Rと組み合わせる
セキュリティはまさに、AIのビルダーモードが見落とすタイプのものだ。だからこそ[C-A-Rプロトコル](/recursos/protocolo-car-construir-sin-bugs)の監査フェーズにぴったり収まる：公開前に監査するとき、この3つの鍵をリストに入れよう。作る側は動くことを考え、監査する側はどう攻撃されるかを考える。
NeuralOSでは、セキュリティは標準装備
NeuralOSでは、あなたが作るアプリはこれらの保護がデフォルトで組み込まれた状態で生まれる——RLS、制限されたオリジン、ヘッダーが、設定を思い出す必要なく最初から入っている。うっかり不安全なものを公開できないようにする、というのが狙いだ。そのビジョンはすでに私たちが作っている道の上にある。