サイトを立ち上げると、何者かからの攻撃を絶えず受け続けることになります。
具体的な被害が発生しない限りサイトのオーナーに報告することはしないので、そういった攻防が行なわれていることはそれほど知られていません。（プラスチックの原料って石油なんですよね、レベルの話ではあります）

セキュリティ対策は挙げれば本当にきりがないのですべてを上げるわけにはいかないので、よくある事例と対策を挙げてみたいと思います。

強制ブラウズ

ログを見ると山ほど見かける攻撃です。
攻撃というよりも実際の攻撃をする前の準備行動として捉えたほうが適切かもしれません。

どういったものかというと、.envや.gitignore、wp-config.php（Wordpressの設定ファイル）のような設定ファイルなどがありそうなURLに直接アクセスして設定情報を取得して、正規のパスワードを盗み出そうとするものです。
通常「.」から始まるようなファイルにはアクセスできない様にしているし、wp-config.phpもアクセスしても空の表示が返るだけなのですが、不適切なバックアップの取り方などをしてしまうと、盗み出されるようになってしまいます。

例えば、wp-config.phpを更新するときに元のファイルを残してすぐに戻せるようにしたいと考えた場合、「wp-config.php.240927」など日付を拡張子の後ろに付けてしまったり、「backup.env」など、「.」から始まらない設定ファイル名に変更してしまうとURL直打ちでそのファイルがダウンロードできてしまいます。

他に、サーバの環境設定を確認するためにphpinfo()を書いたinfo.phpなどを臨時に設置したものをそのままにしておくと、攻撃者にサーバの詳しい情報を渡してしまうことになります。（/info.phpもよくアクセスされています。）
PHPのバージョンやライブラリの詳細が攻撃者にわたってしまうと、選択肢を渡してしまうことになります。

よくありそうなファイル名のダウンロードを試みているログが少ないサイトでも1日数百回、多いところでは数万回見ることができます。

被害

パスワードが漏れる、そこからサーバやCMSの乗っ取りが発生する

対策

サイト更新時に元のファイルは絶対にバックアップとして残さない。
一時的に作って後で消せば良いと思うかもしれないけど、たいてい忘れるので必ず上書きで。
心配ならバックアップを事前に取っておくこと。（パーミッションが問題になることがたまにあるのですが）

info.phpは置いたら必ず削除すること。新人社員がやりがちなので新人には口酸っぱくして教えること。

SQLインジェクション

攻撃者が検索やログイン、お問い合わせのフォームに悪意のあるSQLコードを挿入し、データベースを不正に操作する攻撃です。
DBの中身を窃取する、全部消す、消したうえで改竄したデータを挿入するなど、被害が甚大になります。

未対策のプログラムがあったとして、例えば
ユーザー名フィールドに：’ OR ‘1’=’1
パスワードフィールドに：’ OR ‘1’=’1
と入れると、

SELECT * FROM users WHERE username = '' OR '1'='1' AND password = '' OR '1'='1';

といったクエリが実行されます。
うまい具合にシングルクォーテーションをいれて、予想外の挙動を実行させることで、ログインしていないけどログインしている状態みたいなことを実現できます。

さらに、
ユーザー名フィールドに： ‘ OR ‘1’=’1′; DROP TABLE users; —
パスワードフィールドに： 任意の文字列

というようなログインを実行したとすると、全ユーザ情報が消されてしまいます。

一般的によく訓練されたプログラマーであれば、直接SQL文を実行するのではなく、phpであればPDO、Wordpressであればwpdb::prepareなどSQLを安全に実行できる手段を使用するのが鉄則だとわかっているはずですが、ChatGPTなどのAIはセキュリティを考慮したコードを必ず書いてくれるわけではありません。
AIを使用してコードを書くような、訓練中のプログラマーなどは動作さえすればOK、といった認識の場合があるため、このようなまずいセキュリティリスクは増えていくのではないかと想像しています。

先週の事例ですが、お問い合わせフォームにひたすらSQLインジェクションを繰り返し試した攻撃者からの痕跡が残っていたというものがありました。

対策

DBに問い合わせするような処理までAIに手伝ってもらうなら、必ずSQLインジェクションが起きない書き方になっているかどうかをチェックする必要があります。
（ChatGPTを使う場合、カスタム指示にインジェクション攻撃やXSSの攻撃が起こらない方法で処理を書くように指示を追加しておくと、多少は安全になるかもしれません）

このあたりはある程度の経験のある訓練されたプログラマーが確認することが必要ですね。

クロスサイトスクリプティング（XSS）

POSTメソッドで送られた入力データはWebサーバのログとして残らないし、こういった検索データをどこかに保存するということは稀なので頻繁に起きているかどうかを確認するケースはあまりないのですが、ログを残すようにしておくと、たまにこういった入力があることがわかります。
（攻撃なのか、クライアントがチェックしているのか、同業者がチェックしているのか……。）

前者2つに比べると、掲示板的なシステムでない限り、比較的被害が大きくはならないケースが多いですが、見つかると鬼の首を取ったように「セキュリティリスク【大】」で指摘されてしまうものです。
検索入力欄などに、「」など、javascriptを入れて検索をするとサーバの出力としてjavascriptが実行されてしまうものです。

ユーザが書き込んだ内容がどこかに記録されるようなシステムでは任意の外部のスクリプトを他者に実行させることで個人情報の流出に繋がります。
例えばお問い合わせのフォームなどで、攻撃者がお問い合わせのフォームに外部スクリプトを読み込ませるタグを書いた場合、お問い合わせ管理画面を見に来た管理者の情報が抜き取られる等の可能性があります。
恒久的にデータが残らない、検索窓などでもクエリ文字列を含んだURLをメールで送って踏ませるなどの攻撃で可能らしいので注意が必要です（そんなことあるのか？）

対策

ユーザ入力の情報は必ず出力する直前にサニタイジング（」などと入力してスクリプトが実行されないかどうか確認する

総合的な対策など

攻撃者はプログラムを使用して機械的に攻撃を仕掛けてくることがほとんどの為、captchaなどを使用して、悪意あるロボット的なアクセスを禁止すると効果的なのかもしれません。
GoogleのreCAPTCHAが値上げされてしまったので、今から入れるならCloudflare Turnstileが効果的でしょう。

中露からの攻撃が、我々のような小さなサイトに対してもどんどんと激しくなってきているので、アクティブにセキュリティの対応をしていくとともに、社内でのセキュリティの啓蒙活動を進めていきたいです。