開発者
Grav のプラグインやテーマを作るとき、ベストプラクティスに従うだけではなく、サイトへの潜在的な侵入者に攻撃の道を開けてしまうかどうかを考慮することも、重要です。Grav は flat-file CMS であり、依存関係がほとんどないので、類似のシステムに比べると、安全ですが、危険な経路が不注意で作り出されてしまうことはありえます。
ベストプラクティス
以下は、安全で信頼できる Grav の拡張機能を作成するための推奨事項です。テーマやプラグイン制作者にとって必須の知識です。
- ユーザーが送信した情報を出力する Twig テンプレートを書くときは、常に 入力をエスケープしてください 。また、同じことは assets についても言えます。
- PHP コードは、入力も出力も sanitize してください。
- ブループリントは、事前に用意された選択肢を好んで使うべきです: 可能ならば、ユーザーが、白紙から入力をするのではなく、選択肢から選べるようにしてあげましょう。
- メモリやプロセッサの使用量が、拡張機能にどのような影響を与えるのかを意識し、不当にシステムリソースを消費しないようにしてください。
- テストされていないコードを書くのではなく、Grav の持つ機能と処理のエコシステムを使ってください。それ以上の必要がある場合は、戦場でテストされている サードパーティ製のライブラリ を検討してください。
- 安全でない PHP 関数 を使わないでください。また、セキュリティを主題とする PHP 自身の推奨 と、 PHP セキュリティ コンソーシアム ガイド(リンク切れ)をお読みください。
- スクリプトが失敗するときに、エラーレポートを使わず、特定のエラーに対する 例外(exceptions) を使ってください。決して、例外や公開範囲のデバッグに、ユーザー情報や、インストール情報、システムデータを含めないでください。
Flat-file CMS
Grav の基本的なシステム要件 は、限定的であり、現代的です。特に、 flat-file アーキテクチャが、データベースの必要性を軽減してくれます。これはメリットです。というのも、一般的な攻撃は、システムのデータベースに向かうからです。CMS 全体がデータベースに依存する場合、入力をサニタイズし、安全にするのは、とても大変なタスクです。SQL インジェクション攻撃は、リモートのホスト上でさえ、自動的に SQL文を実行しようとするかもしれません。