2
どのコンテキストでプラグインがデータの検証/サニタイズを担当しますか？
プラグイン/テーマのすべてのデータが、データベースに入る前とブラウザーに出力される前に、安全に処理されるようにします。私の問題は、ポストメタフィールドを保存するときなど、APIがサニタイズを処理する状況と、カスタム設定を保存するときなど、プラグイン/テーマの作成者がそれを行う責任がある状況があることです。 この質問の範囲については、ドメインレベルでのデータの検証については心配していません。たとえば、フォームのAgeフィールドが0〜120であるか、電子メールアドレスが有効であることを確認します。私はセキュリティだけに関心があります。たとえば、データベースへの保存時にSQLインジェクションを回避するためにSQLクエリをエスケープしたり、XSSを回避するためにHTMLテンプレートに出力されるデータを無害化します。 出力のサニタイズについては、変数をHTMLテンプレートにエコーするときなどにesc_html()、常に関数を使用する必要があることを知っていますesc_attr()。しかし、テンプレートタグを使用する場合はどうでしょうか。それらはすべて既に出力をサニタイズしますか？その場合、どのコンテキスト（一般的なHTML、タグ属性など）ですか？一部の関数には、さまざまなコンテキストのバリアントがあります（などthe_title_attribute()ですが、ほとんどはありません 入力サニタイズについては、$wpdb->prepare()手動クエリを作成するときに使用する必要があることは知っていますが、Settings APIを使用してプラグイン設定ページを作成する場合、またはカスタム投稿タイプの投稿メタフィールドを保存する場合はどうですか？ 現在、関数を使用して関数がサニタイズするかどうかを調べるたびにコアを掘り下げてチュートリアルを読んでいますが、それはエラーが発生しやすく、時間がかかります。考えられるすべての状況と、APIがそれを処理するかどうかの包括的なリストを見つけたいと思っています。例えば、 APIの検証/サニタイズ 投稿メタを保存 update_postmeta() ユーザーメタを保存 update_user_meta() 投稿タイトルの出力-コンテキストに応じた適切なバリアントを使用します the_title() 等 手動で検証/サニタイズする必要があります Settings APIを使用してプラグインオプションを保存する。の3番目のパラメーターとしてコールバックを渡しますregister_setting()。 直接データベースクエリ：クエリをにラップします$wpdb->prepare()。 HTMLで変数を出力します。使用esc_attr()、esc_html()など 等 また、特定の状況ではAPIが提供するが、他の状況では提供しない理由を理解したいと思っています。私はそれがデータの未知の性質と関係があると仮定していますが、徹底的な説明を聞きたいです。