Single Post

AppCotton は 外部サイトから使用されるライセンス検証API を扱います。
そのため、認証してはいけない相手 からのアクセスを確実に排除するための設計が必要です。

この章では、次の3つを中心に解説します：

1. Nonce（管理画面内操作の保護）
2. CORS（ブラウザ起点の外部リクエスト制御）
3. ドメイン正規化（アクティベーション判定の統一）

---

1. Nonce（管理画面操作の保護）

目的

• WordPress 管理画面で実行される操作（例：ライセンス削除/解除/更新）に対して
  CSRF（クロスサイトリクエストフォージェリ）攻撃を防ぐ。

AppCotton が保護する対象例

操作	リスク	対策
ライセンスの発行	不正に大量発行	nonce で本人操作を保証
ドメインアクティベーション解除	他人の解除	nonce + user_id 照合
プラン変更	無断アップグレード/ダウングレード	nonce + capability

基本パターン（WordPress準拠）

wp_create_nonce( 'appcotton_action_key' );
check_admin_referer( 'appcotton_action_key' );

実践ルール

• 管理画面内フォーム / AJAX には必ず nonce を付与
• 非ログイン環境 API (例: ライセンス検証) は nonce不要（後述の CORS / ドメイン検証 で防御）

---

2. CORS（外部リクエスト制御）

なぜ必要か

• ライセンス検証 API は、ユーザーが使っている WordPress サイト上の PHP が直接送信するため、
  通常は CORS を必要としません。
• しかし、ブラウザ経由で API を叩く UI を提供する場合（例：フロントの「ライセンス登録画面」）は
  意図しないサイトからの API 呼び出しを防ぐ必要があります。

ポリシー

対象API	CORS	理由
ライセンス検証（PHP → API）	不要	サーバ間通信のみ
JSからのライセンス登録UI操作	必要	ブラウザ起点＝悪用されやすい

推奨設定

Access-Control-Allow-Origin: 同一ドメイン または 許可ドメインのみ
Access-Control-Allow-Methods: POST
Access-Control-Allow-Headers: Content-Type

非推奨

Access-Control-Allow-Origin: *

→ 外部サイトからライセンス登録を代行される危険性があるため禁止。

---

3. ドメイン正規化（アクティベーション判別の統一）

なぜ必要か

ユーザー環境では、同じサイトでも表記の揺れが多い：

https://example.com
https://www.example.com
http://example.com/
https://example.com:443

これらをそのまま比較すると、別ドメインと誤認して上限超過扱いになってしまう。

正規化ルール（推奨実装）

処理	例	結果
スキームを除去	https://example.com	example.com
www. を除去	www.example.com	example.com
末尾 / を除去	example.com/	example.com
ポート番号を除去	example.com:443	example.com

→ 同一ルートドメインまたはサブドメイン単位で管理

サブドメインは区別するか？

運用方針	想定用途	判定例
区別する（推奨）	SaaS / multi-tenant / 教室 / 店舗	site1.example.com ≠ site2.example.com
区別しない	大規模 WP マルチ環境の簡略運用	www.example.com = example.com

AppCotton のデフォルト

• www は除去
• サブドメインは 区別する
• ルートドメイン単位で保存

---

まとめ

項目	役割	影響する場面	必須度
Nonce	管理画面の操作を保護	ライセンス発行/削除	★★★
CORS	Webブラウザからの不正呼び出し防止	公開UIでのライセンス登録	★★☆
ドメイン正規化	正しいアクティベーション数管理	サイト移設/複数環境利用	★★★

技術的な防御（Nonce / CORS）と、
ライセンス体験を損なわない設計（ドメイン正規化）が両輪です。