セキュリティ監査

AIにアプリのセキュリティ状態をレビューするよう依頼し、以下のベストプラクティスに従い、シークレットは Settings ページで管理してください。

Proyecta のセキュリティは、プラットフォームのデフォルト設定、AIによるレビュー、そしていくつかの習慣の組み合わせによって実現されます。考え方を整理しておきましょう。

セキュリティ監査を実行する

Command Palette（Cmd+K / Ctrl+K）を開き、Run Security Audit を選択します。これにより、包括的なセキュリティプロンプトがAIに送信され、コードベース全体を読み込んで、優先順位付けされた発見事項と具体的な修正方法とともに脆弱性を提示します。

監査では以下の項目をチェックします：

ソースファイルにハードコードされたAPIキー、トークン、またはパスワード
クライアントにシークレットを漏洩させる VITE_ プレフィックス付き環境変数
APIエンドポイントでのサーバーサイド入力バリデーションの欠如
認証が設定されていないページやAPIエンドポイント
エスケープされていないユーザーコンテンツ（XSSリスク）
依存関係の脆弱性
混在コンテンツまたはハードコードされた http:// URL
ファイルアップロードバリデーションの欠如

チャットから手動でセキュリティ監査を実行したり、特定のエリアに絞り込んだりすることもできます：

"Review my checkout flow for security issues"
"Check the admin pages — who can access what?"
"Look at every endpoint that writes to the database and tell me if any of them are missing authorization"

セキュリティのベストプラクティス

シークレットを安全に保管する

すべてのAPIキー、データベース認証情報、サードパーティトークンを Settings ページの環境変数セクションに保存する
シークレットをチャットメッセージに貼り付けたり、コードにコミットしたりしない
シークレットが漏洩した場合は、すぐにサードパーティプロバイダーで無効化し、新しいものを作成する

アクセスを制限する

アプリにロールベースの権限を実装する（"Add admin and member roles. Only admins can access /admin pages."）
機密ページとエンドポイントを認証済みユーザーのみに制限する
ユーザー入力は常にサーバーサイドでバリデーションし、クライアントサイドのみに頼らない

どこでもHTTPSを使用する

公開されたすべての Proyecta アプリは自動的にHTTPS経由で配信される
SSL証明書は自動的にプロビジョニングおよび更新される
カスタムドメインの場合も、DNSが正しく設定されていれば同様に適用される

依存関係を最新の状態に保つ

AIに定期的に確認する："Check my dependencies for known security vulnerabilities and upgrade the vulnerable ones."
AIが行った変更をレビューする — 依存関係のアップグレードには破壊的変更が含まれる場合がある

大きな変更後に監査を行う

認証、決済、ファイルアップロード、またはユーザーデータに触れる機能を追加した後は、再度監査を実行する
初めて本番環境に公開する前に、全体的なチェックを行う

Proyecta が代わりに処理すること

HTTPSと証明書 — *.proyecta.live サブドメインに対して自動で提供
アプリデータの保存場所 — アプリのコンテンツ、レコード、カタログは Proyecta プラットフォームのデータ層（Postgresベース）に保存され、組織ごとにスコープが設定され、保存時に暗号化されます。公開されたアプリは publishable key（pk_pub_*）を使用してこれにアクセスします。このキーはページに含めても安全です。サーバーは匿名リクエストを公開コンテンツのみに制限し、管理者操作には適切なロールを持つサインイン済みセッションが追加で必要になります。すべてのリクエストは組織単位で認可されるため、あるアプリが別のアプリのデータを読み取ることはできません。
環境変数 — シークレットは専用のシークレットストアに保存され、必要に応じてアプリのバックエンドに同期され、コードベースにはコミットされません。なお、シークレットはプロジェクトにアクセス権を持つワークスペースメンバーには表示されます。
分離されたランタイム — 各プロジェクトは独自のコンテナで実行されるため、開発環境の問題が他のユーザーに影響を与えることはありません

ヒント

初回公開前に監査を実行する — 全体的なチェックを行うことで、問題が公開される前に発見できます。
大きな変更後に再実行する — 認証、決済、ファイルアップロードの追加は、新たな攻撃対象領域を生み出します。
スコープを絞り込む — 特定のエリアに対する監査は、アプリ全体のチェックよりも高速かつ徹底的に行えます。