フォームのセキュリティ設定周りについて学びましょう。

フォームは、一般ユーザーが送信できる箇所になり、セキュリティをしっかりと考えないといけない箇所になります。 標準的なセキュリティ対策は標準でされていますが、フォーム設定などによってもよりセキュリティを高めれますので、設定する意味や設定内容をここで学びましょう。

入力チェック

できる限り、テンプレートで指定したバリデーションは、「フォーム設定（管理画面でのフォーム詳細画面）」でもするようにしましょう。
ここの設定をおこたると、少しHTMLの知識のある人なら、開発者ツールでHTMLを変更し、バリデーションを突破されてしまう為になります。

テンプレートでのバリデーション設定

テンプレートでのバリデーション設定は以下のコードのようにHTMLによって設定できます。 ただし単なるHTMLコードなので、ブラウザの開発者ツールなどを利用すると、簡単にバリデーションの記述を削除して突破されてしまいます。

<input type="text" name="name" value="{name}" data-validator="name" />
<input type="hidden" name="field[]" value="name" />
<input type="hidden" name="name:v#required" value="" id="name-v-required" />
<div data-validator-label="name-v-required" class="validator-result-{name:v#required}">
  <p class="error-text">
    <span class="acms-admin-icon acms-admin-icon-attention"></span>名前は必須入力です。
  </p>
</div>

フォーム設定でのバリデーション設定

フォーム設定でバリデーション設定すると、サーバーサイドでのチェックになるので、攻撃者はこのバリデーションを突破できなくなります。

メールアドレスのテンプレート指定

メールアドレスの「テンプレート指定」は出来るだけ無効化させましょう。 バリデーションと同じようにテンプレートでの指定は、攻撃者がブラウザの開発者ツールなどで、自由に変更できてしまいます。 必要のない項目は「テンプレート指定を無効」にチェックをつけて無効化させましょう。

おすすめ設定

以下は、おすすめの設定内容になります。

一般メール設定

お問い合わせ者に自動返信するメールの設定になります。 お問い合わせ者に送信先メールアドレスさえフォームで入力してもらえればいいので、「To」以外はテンプレートで指定できないようにします。

管理者宛メール設定

管理者宛メールは、送信先が決まっているので「AdminTo」をテンプレートで指定できなくします。

「AdminFrom」はお問い合わせ者のメールアドレスをテンプレートで設定することも多いと思いますが、おすすめとしては「AdminFrom」も固定にしてしまいます。 というのも、メールはCMSがあるサーバー、またはSMTPサーバーから送信されますので、Fromのメールアドレスドメインと送信サーバーが合わずFromの偽装にあたり迷惑メール扱いになる可能性が高いためになります。

ただ、このままでは管理者に届いたメールを返信しようと思っても、返信できないので「AdminReply-To」にお問い合わせ者のメールアドレスをテンプレートで指定するようにします。 これで、メーラーで返信する時、お問い合わせ者に返信できるようになります。

複数指定

特に理由がない限り複数指定できないようにチェックをつけましょう。
複数指定できてしまうと、フォームで大量のメールアドレスをカンマ続きで指定する事により、大量のメールを送信できてしまうことになります。

そもそも自動返信メールを送らない

問い合わせ受け付けメール（自動返信メール）を投稿者アドレスに送信しない設定にするのも方法の一つです。 この場合、そもそもメールが送信されないので、セキュリティを高めることができます。

ただしお問い合わせ者が正常にメールが送信されたか判断しずらいので、ここは、利便性とセキュリティを比べて判断するようにしましょう。

メール送信しないように設定する方法

フォーム設定で、メールアドレスを全て空にして、テンプレートからも指定できなくしましょう。これでメールは送信されなくなります。

reCAPTCHAの導入

標準機能ではありませんが、よりフォームのセキュリティを高めるために、ロボットか判断するGoogleの「reCAPTCHA」サービスと連携する方法がございます。
a-blog cms の拡張アプリとして用意されていますので、こちらもご検討ください。

https://github.com/appleple/acms-recaptcha

この記事では、2025年10月28日にリリースした Ver. 3.2.6 と Ver. 3.1.59 の修正内容について紹介いたします。

現在お困りの問題に該当する項目がありましたら、お早めにバージョンアップのご検討をお願いいたします。

リリースノート

Ver. 3.2.6 修正点

• CMS-7385 非推奨警告の監査ログの肥大化に対応するため、同じログを24時間に1回までになるように改善
• CMS-7389 v3.2.4 より Entry_Body で Undefined array key 'y' エラーが発生する問題の修正
• CMS-7390 v3.2.4 より V2_Category_EntrySummary でphpエラーが発生する問題の修正
• CMS-7391 v3.2.4 で メディアユニットにファイルのメディアを登録した場合、アイコンの x, y 変数が出力されない問題の修正
• CMS-7392 カスタムフィールドメーカーが表示されない問題
• CMS-7393 管理画面のカラーピッカーをブラウザ標準の機能に変更
• CMS-7395 V2_Entry_Bodyのスニペットのタグ表示部分の条件式を修正
• CMS-7397 Develop テーマ を v1.0.3 を更新

Ver. 3.1.59 修正点

• CMS-7394 管理画面のカラーピッカーをブラウザ標準の機能に変更

a-blog cms では複数のキャッシュを使い、パフォーマンスを高めています。
ここでは使用されているキャッシュの種類とクリア方法を確認しましょう。

キャッシュの種類

ページ キャッシュ

CMSでレンダリングされたHTMLをキャッシュします。このキャッシュにより2回目のアクセスは、ほとんどのCMSの処理を飛ばすことができるので、 表示速度に大きく影響します。特に理由がなければ「有効」にしましょう。詳しくは「ページキャッシュについて」をご確認ください。

テンプレート キャッシュ

テンプレートをキャッシュします。テンプレートキャッシュがあることにより、テンプレートの組み立てを毎回することがなくなるので、 ページ表示速度が高速になります。テンプレート修正した時などはキャッシュをクリアする必要があるため注意事項がいくつかあります。 詳しくは「テンプレートキャッシュについて」をご確認ください。

コンフィグ キャッシュ

CMSのコンフィグ設定をキャッシュします。特にキャッシュについては意識する必要はなく、コンフィグを変更すると自動的にキャッシュはクリアされるようになります。

カスタムフィールド キャッシュ

コンテンツのカスタムフィールド情報をキャッシュします。特にキャッシュについては意識する必要はなく、コンテンツ更新時などに自動的にキャッシュはクリアされるようになります。

モジュール キャッシュ

モジュールの出力情報をキャッシュします。モジュールID化してキャッシュを設定した場合 や、Feed_ExListモジュールやJson_2Tplなどの外部アクセスが必要なモジュールでも利用されます。

一時的なキャッシュ

さまざまな情報をキャッシュします。例えばエントリーの情報や、プログラムの変数などをキャッシュしています。 特にキャッシュについて意識する必要はなく、コンテンツ更新時などに自動的にキャッシュはクリアされるようになります。

キャッシュのクリア方法

キャッシュのクリア方法について説明します。

ページキャッシュ以外のクリア方法

ページキャッシュ以外のキャッシュは 「ルートブログ」で「編集者以上」 のユーザーのみキャッシュのクリアが可能です。 ルートブログのダッシュボードで、クリアしたいキャッシュにチェックをつけて「キャッシュをクリア」ボタンを押してください。

ページキャッシュのクリア方法

ページキャッシュのクリアは「編集者以上」のユーザーが各ブログでキャッシュをクリアできるようになっております。
ダッシュボードで「ページキャッシュ」にチェックをつけて「キャッシュをクリア」ボタンを押してください。