AIが出したコードをそのまま公開して、気づいていなかった穴

• 動くことと、公開して安全なことは別
• 入力を受け取る箇所は、必ず確認が要る
• 読めなくても、確認できる項目はある

簡単な問い合わせフォームを作って公開していた。動いていたので満足していたが、後から見直して問題が見つかった。コードが読めなくてもできる確認を整理する。

何が問題だったか

指摘されたのは、入力された内容の扱いだった。

• 入力された文字をそのまま画面に表示していた
• 送信元の確認をしていなかった
• 送信回数に制限が無かった

どれも動作には影響しない。正しく使われている限り、問題は表に出ない。だから気づかなかった。

なぜ出力に含まれなかったか

振り返ると、こちらが頼んでいなかった。

「問い合わせフォームを作って」と頼めば、問い合わせフォームが返る。安全性について触れなければ、最低限の作りになる。頼んでいないことは入らないという、当たり前の話だった。

頼むときに足すようにした一文

いまは必ずこれを添えている。

公開するものです。次を考慮してください。
- 入力された内容を、そのまま画面に出さない
- 送信元を確認する仕組みを入れる
- 短時間に大量送信された場合の制限を入れる
- 入力の形式と長さを検査する

それぞれ、何をしているか説明を付けてください。

最後の1行が重要だった。説明が付いていれば、読めなくても何をしているか分かる。

読めなくてもできる確認

コードが読めない前提で、確認できる項目を挙げる。

• 入力欄に長い文字列を入れてみる。受け付けてしまわないか
• 記号を入れてみる。画面が崩れないか
• 空のまま送信してみる。エラーになるか
• 同じ内容を続けて10回送ってみる。止められるか

どれも実際に触れば分かる。読む代わりに、試すという形で確認できる。

記号を入れる確認

山括弧や引用符を入力して送信し、結果の画面が崩れないか見る。崩れるなら、入力がそのまま扱われている可能性がある。

公開前に見る項目

手元で動いた後、公開する前に通している確認を並べる。

• スマホで開く。崩れていないか
• 別のブラウザで開く。片方だけで確認して終わらせない
• 想定外の入力を入れる。空欄、長文、記号
• 通信の記録を見る。読み込みに失敗しているものがないか

4つ目で、外部のファイルを読み込んだままになっているのを見つけたことがある。開発中に使った読み込みが残っていると、意図しない場所と通信し続ける。

自分で判断できないもの

試しても分からない部分もある。そこは割り切った。

• 保存されたデータの扱い
• 通信の暗号化
• 権限の設定

これらが絡む場合は、自分で作るのをやめた。既にある仕組みを使うか、分かる人に見てもらう。

見落としやすい設定

コード以外にも、公開時に確認する点がある。

• 作業用のファイルが残っていないか。控えや古い版
• 設定を書いたファイルが、外から見えないか
• エラーの詳細が、画面に出る設定のままでないか

3つ目は実際にあった。エラー時にファイルの場所や構成が画面に表示される設定のままで、内部の作りが外から見える状態になっていた。公開前に、エラー表示を切る設定に変えるのを手順に入れた。

既存の仕組みを使う

結局、問い合わせフォームは専用の仕組みに置き換えた。

• 多くの人が使っていて、問題が見つかれば直される
• 設定だけで済み、作る必要がない
• 更新を当てていれば、一定の水準が保たれる

自分で作ると、問題が見つかっても誰も教えてくれない。これが一番大きな違いだった。

作ってよいものの線引き

いまはこう分けている。

• 作る — 手元で動かすもの。人のデータを扱わないもの
• 作る — 表示するだけのもの。入力を受け取らないもの
• 作らない — 入力を受け取るもの
• 作らない — ログインや支払いが絡むもの

入力を受け取るかどうかで線を引くと、判断しやすかった。

まとめ

• 動くことと、公開して安全なことは別
• 頼んでいない配慮は入らない。安全性は明示して頼む
• 「何をしているか説明を付けて」と添えると、読めなくても分かる
• 長い文字列・記号・空欄・連続送信を試せば、読まずに確認できる
• 入力を受け取るものは、既存の仕組みを使う