SQLコードインジェクション防止の８のベストプラクティス
第4章です。
序章
1. クライアントサイドの入力バリデーションに依存しない
2. 制限された権限を持つデータベースユーザーを使用する
3. プリペアドステートメントとクエリパラメータ化を使用する
4. コードをスキャンしてSQLインジェクションの脆弱性を探す
5. ORMレイヤーを使用する
6. ブロックリストに依存しない
7. 入力バリデーションを行う
8. ストアドプロシージャに注意する
4.コードをスキャンしてSQLインジェクションの脆弱性を探す
カスタムコードを作るのは簡単でしょう。しかし、間違いが簡単に起こります。コードをチェックするために、コードレビューやペアプログラミングなどのプロセスを用意しているかもしれません。しかし、ペアでコードをレビューする人は、セキュリティに精通しているでしょうか。ペアの方は、あなたのコードにあるSQLインジェクションのバグを発見できるでしょうか。いずれにしても、SQLインジェクションのようなセキュリティ上の脆弱性の可能性がないか、カスタムコードを自動的に調べることができるに越したことはありません。Snyk CodeのようなSAST（Static Application Security Testing）ツールを使用し、SQLインジェクションなどのセキュリティ上の脆弱性がないかコードを自動的に検査することができます。たとえばGitリポジトリをSnykに接続することで、SDLCで簡単に自動化することが可能です。
4つめは以上です。
最後までお読みいただきありがとうございました！
次回はSQLインジェクションを防ぐ 〜5に続きます。
SQLインジェクションに関する英語全原文はこちらです。
Contents provided by:
Jesse Casman, Fumiko Doi, Content Strategists for Snyk, Japan, and Randell Degges, Community Manager for Snyk Global