前置き
脆弱性の発覚や不正アクセスが頻発
自分は新卒からIT業界でPG･SEとして10年弱、計4社（+一時期副業でフリーランス並行）でWebアプリケーション開発に従事した。数年前にIT業界に見切りをつけたため、今は全く関係ないアナログ多めの業界で別業種として働いている。
IT業界ではPHP（当時で7系）に携わっていたときもあり、LaravelとCakePHPはそれなりに触った。IDEはJetBrainsがお気に入りでPhpStorm信者だった。
特段セキュリティに詳しいわけでもなく凡人のため、古い知識や技術を根拠に書いている部分もあるが、思ったことを書いていく。一部対策も書いてたりするが、当然これで全部という訳ではなくほんの一例である。
今となってはこの程度ならAIで何とでも書けるため、IT業界にいた証拠だけアップロード。紙の色が違うのは期間が開いてるからなのか・・・？AWSはSAAのみ取ったが、期限切れ。
世界中の数多くのWebサービスがPHPで動いている
当ブログもPHPとWordPressで動作（バージョン修正済）
日本時間2026/10/21 23時、PHPの脆弱性を修正したバージョンが公開された。
それまで各所で不正アクセスが頻発していたことから、PHPの件もニュースで多く取り上げられていた。自分が従事していたサービスのうち、オープンなサービス（名前ははっきりと憶えている）を巡回してみたら絶賛メンテ中だった。
今となっては対岸の火事だが、深夜まで障害対応させられた身としては、いたたまれない気持ちである。
もし興味本位でPHPが使用されているかどうかを知りたいのであれば、利用者側が知る簡単な方法のうちの１つは、ブラウザの拡張機能を入れることである。
自分が使用しているのは「Wappalyzer」というchromeの拡張機能。サイトにアクセスするだけで、そのサイトが使用している技術（プログラミング言語、Webサーバやフレームワーク、CDN、PaaS、各種分析ツール等）を見ることができる。100%正解というわけではないが、大まかにはあってそう（主観）と思っている。
そこにもしPHPやWordPress、Larravelなどと書かれていたら、PHPが使用されている。
なぜわかるのか？それは、Webサイトにアクセスする際のやり取りで返されるWebレスポンス内に、特有の情報が吐かれるためだ。拡張機能はこの情報を見て視覚的にわかりやすく表示してくれているだけであり、この情報を見ることは何ら問題ではない。（拡張機能がなくとも確認することは可能だ）
しかし利用されている技術を知っても、サービスの利用者側がどうにかできる問題ではないのが現実だ。
PHPの役割
インターネットの先にあるWebサーバ上でPHPが動いている
我々がPCやスマホでWebページにアクセスするとき、インターネットを経由した先にあるWebサーバがサイトの情報を返してくれている（※１）。こちらからの要求（リクエスト）と、Webサーバからの応答（レスポンス）で成り立っているというわけだ。
PHPは主に、Webサーバ上の処理を担うプログラミング言語の１つだ。PHP以外にも選択肢があるわけだが、それなりに歴史が長く継続的なメンテナンス（サポート）体制があることや技術者が多いことから、よく選択されがちだ。アプリケーション開発の実務でも、プログラミング言語やフレームワークなど技術選定をするのだが、大抵は人員確保や学習コスト、開発工数削減の観点で議論の余地もなく、消去法で自動的に決まっていた。
また、メジャーなオープンソースのサーバ構築構成で、LAMP環境（Linux & Apache & MySql & PHPの頭文字）といわれる、入門から小中規模までなら普通に使えるテンプレート的な構成として知られている。
※１ 記載しているのは、最も基本的な最低限のパターンである。
実際はWebサーバとアプリケーションサーバ、DBサーバが分かれていたり、Webサーバより前に特定のコンテンツだけを返すCDNや、負荷を分散させるLBがあったり、Webサーバが複数並列に並んでいたりコンテナという単位で可動していたりと、顧客のシステムの要求に応じて設計パターンは非常に多岐にわたる。
サービス利用者側で対策できること（初級）
パスワードを複雑に
原始的だが、誰でも簡単にすぐにできる対策
すぐにできそうなのは以下。パスワードそのものを何で管理するか議論に関しては、好みの問題もあるためここでは取り上げない。
パスワードは一般的に、データべ―ス上に平文（そのままの状態）では保存せず、ハッシュ化（複雑な文字列に変換）した上で保存する。ハッシュ化は不可逆性という元に戻せない性質を持つため、ハッシュ化された複雑な文字列を元のパスワードに復元することは一般的には不可能とされている。（天文学的な計算が必要とされている）
一般的なログイン処理において、パスワードを入力してログイン処理を行っても、入力してパスワードをハッシュ関数に通した値と、データベース上に登録されている（すでにハッシュ化されている）パスワードを照合した上で判定する。
察しの良い人は、じゃあ流出しても問題ないのでは？と思うかもしれないが、使用するハッシュのアルゴリズムやSaltキーの使用有無によっては、割り出すことが可能とされている。古いシステムや、適当にコピペした上でコードレビューも通さずリリースされたシステムの場合は普通にあり得えてしまうのが現実だ。
VPNなしでのフリーWiFiを避ける
盗聴の可能性あり
フリーWiFiに接続するということは、他人と同じローカルネットワークに接続するということ。生身で盗聴される機会を自らつくりにいってるということだ。
現代では多くのサイトがHTTPS通信で保護されているため一般的には安全であるとされているが、絶対という保証はない。また、もしHTTPSに対応していないサイトにアクセスした場合、その通信内容は保護されないため、アクセス先や入力したフォームデータの読み取りはフリーソフトをですら可能である。
HTTPS通信に対応しているかどうかは、アクセス時にブラウザで「保護されません」みたいな警告が出てこなければ基本的にはOKだ（※１）。HTTPS通信の対応は、アクセス先のサイト側でSSL証明書やらの設定が必要であり、サイトの管理者が動く必要があるため、不安ならそもそもアクセスしないのが吉。
※１：HTTPS有無の観点でOKというだけで、他の観点含めてそのサイトが安全かどうかまではブラウザはわからない。
人目がある場所で、機密事項を扱うPC利用を避ける
物理的に画面を盗み見られるリスクを舐めてはいけない
これは前述した公共WiFiとは切り離して考え、物理的に画面を盗み見るという、れっきとした攻撃手法である。
このような攻撃をソーシャルエンジニアリングやショルダーハッキングと呼び、（今は知らんが）昔の情報処理試験の午前問題でも出ていたほど初歩的なものである。初歩的とは言えど、盗み見ること自体が特別なデバイスや技術がなくても可能なこと、シチュエーションによっては盗み見た人物の特定が困難であることを忘れてはいけない。
もちろん、機密情報がない場合は自由にしていいのだが、たった数秒チャットやメーラを開くだけでもリスクは生じる。カフェで堂々とPC開いて仕事している人達はどこまで意識しているのか、未だに疑問である。
サービス利用者側で対策できること（一部有料）
VPNを使用
VPN→ネットワーク上に仮想の専用線を引くイメージ
VirtualPrivateNetworkの略で、文字通り仮想&プライベートなネットワーク通信を可能にする技術だ。これを使用している限り、公共WiFiでも通信は暗号化されるため、安全性を担保できる。
利用するには基本的にはVPNアプリを入れるだけだが、無料のものから有料のものまで数多く存在するため、アプリの提供元が信頼できるかかどうかや、他の機能もあわせて選択する必要がある。
自分の場合、普段はそもそも公共フリーWiFiにアクセスしないため、旅行のときのみピンポイントでNordVPNを1ヶ月だけ契約して、そのときだけフリーWiFi+VPNで使用している。
新たに電話番号やメールアドレスを取得して使い分ける
流出を前提にするという考え方
データ通信&発信をしない前提で、サブ用の電話番号を新たに取得するだけなら、今時1回線500円もかからない。下手なサブスクを契約するよりも合理的だと思うのは自分だけだろうか。
メインの電話番号はプライベートで親密な人物と一部の書類にしか使用しない。それ以外はサブの電話番号で登録している。セキュリティ対策だけでやっているわけではなく、半分は趣味みたいなもので取得したものだが、使い分けているのは事実である。
回線を増やしたとして、スマホを２台持たないといけないのか？
今時のスマホならiPhone・Android問わず多数の機種がDSDVに対応しているため（念のため、要確認のこと）、１台のスマホで２回線を同時に待ち受けさせることは、容易である。DSDVについて掘り下げると逸脱するため、これは個々で調べていただきたい。
もちろん、名前や生年月日など追加や変更できないものがあるため、根本的な解決ではない。
対策しても意味なさそうなこと（サービスの仕様次第）
退会する
多くのサービスは退会後もユーザデータを残す
とあるサービスで退会したとしたら、登録していた情報は削除されて安全だと思い込んではいないだろうか？その答えはNoである。少なくとも、自分が過去に携わったシステムはすべてそうだった。
これは実際にデータそのものが完全に削除されたわけではなく、過去に利用していたユーザが、退会済みとしてマークされただけだ。サービス上、アクティブなユーザとして参照されなくなるだけで、データベース上ではしっかりと残っているのである
このように、参照されないように制御することで、削除したように振る舞う削除方法を論理削除といい、それと対照的なのが物理削除である。決して特殊な削除の仕方というわけではなく、ごく普通のデータベース設計の手法である。
何なら退会においては論理削除ですらなく、ユーザが退会済みという状態になっただけ、という扱いですらある。
物理削除されていない以上、サービスの管理者や運用者のうち権限がある人は、引き続いてそのデータが閲覧可能だ。そして、特に零細やベンチャーで人員がまだ少ない場合は、開発者=運用者なことが多く、属人的な作業を減らすために開発者全員が本番環境のデータベースへのフルアクセス権を持つことも普通である。
ダミー情報に変更する
意味がない可能性がある上に、サービスによっては利用規約に抵触する恐れも
自分が関わったサービスでは、変更前のデータを残していないものもあれば、残していたものもあった。実際にそのサービスが残しているかどうかは、利用者側では判断できないのが現実だ。サービス利用者側に表示されるのが最新のデータであっても、変更前のデータはデータベース上に残ったままの可能性があるというわけだ。
リスクを減らすためにも変えておいて損はなさそうであるが、確実に本人であることが求められるサービスにおいては、ダミー情報に変更し本来の個人情報と不整合が発生することで利用規約に抵触する恐れがあるため、注意が必要だ。
セキュリティ対策は利益に現れない
これまではセキュリティ対策をしたところで、エンドユーザはその恩恵を感じづらく、営業的にも売り文句にもしづらかったのだ。営業的には新しい機能を追加した方が売りやすい、という主張も理解してはいるつもりだ。
セキュリティに関しては、（対策したことが利益に現れなくとも）何も起こらなかった、ということが本番環境における何よりの成果なのである。ただし、本当に何も起こらなかったのか、ただ気づかなかったのかは明確にするべきである。
自分が従事していたときも、BtoBtoCのサービス開発でセキュリティエンジニアがざっと確認した上で、さらに第三者機関によるテストを提案していたことがあったが、拒否されて肩身狭そうにしていたことは忘れられない。
このように何かと疎かにされがちなセキュリティだが、さすがにこの一連の騒動があったため今後は考えを改めるべきである。
今になって急遽、その尻ぬぐいをさせられているのは技術者なのだ。
