複数の人間が使用するサービスにおいて、ある人間が他の人間の公開していない情報を取得、改竄できてしまう状態、もしくはその手段のこと。
「脆弱性」とも言う。
たとえば、インターネットに公開されたWebアプリケーションで、パスワードに"ZZZZZ"を入力すると誰でもログインできてしまい、他人の情報を取得することができる、というのがセキュリティホールのひとつである。
　
多人数で使用するサービスの場合、使用する人間はサービスに自分の情報を登録する。
登録された情報は、そのサービスによって管理されるため、ある人が登録した情報を、他の人が勝手に取得・改竄できないようにする必要がある。
そのため、サービスは個人情報を保護しなければならない。それぞれの個人情報が、本人にのみ取得・変更可能とし、他の人間から保護する。
この「保護」に穴があり、他の人間が個人情報を取得できてしまう、その「穴」がセキュリティホールである。
　
Webアプリケーションにおけるセキュリティホールの代表的なものに、以下のようなものがある。
　
・クロスサイトスクリプティング（XSS）
・SQLインジェクション
・CSRF
　
ただし、これら以外にも多くのセキュリティホールが存在する。
たとえば前述したように、パスワードの管理はセキュリティホールとなりやすい。テスト用のパスワードを直接設定していたり、パスワードの設定時に文字数の制限を設けていなかったり、といったことがセキュリティホールとなりやすい。
その他にも、最後の「完了画面」への直接アクセスや、入力フォームを用いずリクエストを生成しての実行等、考慮しなければならない箇所は非常に多く、その全てを塞がなければ、どれかがセキュリティホールとなる。
　
残念ながらセキュリティホールに対する開発者の意識は必ずしも高くない。
セキュリティホールの対策は工数の増加となるため、価格へと反映されたり、工期を圧迫する。
また、セキュリティホールを知るためには最新の技術に精通していなければならないが、営業や上層部がそれらに疎く、対策の実装をプロジェクトとして行わないことも多い。
設計者と実装を行うプログラマーとの間の温度差により、どちらも対策の必要性を考慮せず、結果的に実装されないこともある。
イントラネットの場合には「運用でカバーできる」「社員に悪い人間はいない」、インターネットの場合には「何もしなければばれないだろう」という意識が、積極的な対策を怠らせる原因となる場合もある。
最近はセキュリティホールによる問題がニュースに昇ることも多いが、それが逆に「慣れ」となり、現場の意識低下に継ながっている面もある。
　
逆に言えば、セキュリティホールを潰すためには、個々人の意識とプロジェクト全体の意識が一致団結する必要がある。
個々人が問題意識を高め、その意識をプロジェクトは汲み取り、工期や要因追加において実質的なサポートを行うことで、セキュリティホールを減らすことができるだろう。

「航空会社がコストカット優先する時代だよ？　どこの顧客もそんなん考えないって」
「またみもふたもないことを……」