Gyazoの不正アクセスと2,362万件の流出｜第三報の原因と利用者の点検手順

画像共有サービスGyazoを運営するHelpfeelは2026年10月21日、外部専門機関のフォレンジック調査を踏まえた第三報を公表し、これを調査結果の最終報告と位置づけました。原因は、アップロードされた動画などを変換する処理で、外部からの入力値がサーバー上のコマンドとして解釈されてしまう脆弱性でした。流出したのはユーザー情報約2,362万件と画像メタデータで、特定ユーザー133名の画像432件は第三者に閲覧・取得されています。この記事では第一報から第三報までの公表内容を整理し、利用者が今やる点検、業務で使っていた企業の確認範囲、アップロード処理を持つサービスの実装対策を、実行して確かめたコードで示します（2026年10月24日時点）。

まとめ：Gyazoの不正アクセスで確定した事実と今やること

• 2026年9月11日午後から12日未明にかけて、動画等の変換処理の脆弱性から任意のコマンドを実行され、変換用サーバーから届くデータベースの中身を外部へ送信されました。脆弱性は9月12日に修正済みです。
• 外部の部品や委託先が原因のサプライチェーン攻撃ではなく、Helpfeelが自社で開発・運用するコードの脆弱性です。
• 流出範囲はユーザー情報約2,362万件、画像メタデータ約4.9億件、条件を絞って取得されたメタデータ約240万件、削除済み画像のメタデータ約1.74億件、特定ユーザー133名の画像432件です。決済情報、画像ファイルの大量取得、HelpfeelとCosenseへの影響は確認されていません。
• 2026年10月20日時点で二次被害は確認されていません。不正アクセス前の画像は所有者本人が確かめてから配信を再開する方式で、Helpfeelはこれを恒久的に続けるとしています。
• 利用者は、Gyazoと使い回し先のパスワード変更、X連携の解除、配信再開前の画像の棚卸しを進めます。OCRテキストと取得元URLは取り消せないため、業務画面を撮っていた場合は写っていた鍵や管理画面の扱いまで決めてください。

公表内容の時系列｜9月11日の侵入から10月21日の第三報まで

Helpfeelの発表は、第一報（9月16日）、HelpfeelとCosenseへの影響に関する9月18日のお知らせ、第二報（9月25日）、サービス再開のお知らせ（9月26日）、第三報（10月21日）の5本です。再開のお知らせはページの日付が9月26日、再開日が9月27日です。下の表の日付は第三報の経緯表に合わせています。

第二報で増えた削除済み画像のメタデータ約1.74億件

第二報では、主に2023年2月以前に削除された画像のメタデータ約1.74億件も流出していたと追加されました。第三報では、2023年2月以前にアカウントを削除したユーザーが所有していた画像も対象に含むと明記されています。削除済み画像のファイル本体は含まれません。同じ第二報で、ユーザー情報約2,362万件の内訳が匿名ユーザー約1,801万件（約76%）、メールアドレス登録ユーザー約562万件（約24%）と示されました。件数はアカウント数で、人数ではありません。

9月27日の再開で過去画像が「本人のみ閲覧」になった仕組み

サービスは9月18日から止まり、9月27日に再開しました。不正アクセス前にアップロードされた画像は、以前の公開範囲にかかわらず所有者本人しか見られない状態になっています。配信の再開は、画像ページで1枚ずつ、一覧で複数を選んで、設定ページの「配信停止中の画像」から全件まとめて、の3通りです。再開した画像には本件発生前の閲覧範囲がそのまま戻ります。9月29日の追記で、Gyazo Teamsの過去画像は配信停止中でも同じチームのメンバーが見られる仕様に変わりました（「自分のみ」設定は除く）。第三報は、この本人確認を経る方式を恒久的に維持し、同社の判断で一律に再開することはないとしています。

第三報で確定した二次被害の状況と今後の連絡

第三報によると、10月20日時点で個人情報の不正利用やなりすましなどの二次被害は確認されていません。同社は9月下旬からダークウェブ等で流出情報が売買されていないかを監視しており、少なくとも1年続けるとしています。削除済みメタデータの対象のうち、連絡先のメールアドレスが分かる約5.7万アカウント（退会済みを含む）には、第三報の公表後に順次メールが届きます。

このメールは、URLへのアクセスやリンク先での操作を求めません。同社が本件でパスワードやクレジットカード番号を尋ねることもないと明言しています。本件の案内を名乗りながらリンク先での操作やパスワードの入力を求めるメールは、Helpfeelの説明と食い違います。開かずにGyazoの問い合わせ窓口で確認してください。

不正アクセスの原因｜動画等の変換処理で起きたコマンドインジェクション

第三報によると、原因は画像アップロードサーバーで動画等を変換する処理の一部に、外部からの入力値が適切に処理されないままサーバー上のコマンドとして解釈される脆弱性があったことです。第三者はこれを使って変換処理用のサーバーで任意のコマンドを実行し、そのサーバーから到達できたデータベースに接続して大量のデータを読み取り、外部のサーバーへ送信しました。分類としてはOSコマンドインジェクションにあたります。仕組みと言語ごとの対策はOSコマンドインジェクションとは？仕組みと引数配列で防ぐ実装で解説しています。

Helpfeelは、外部のソフトウェア部品や委託先が原因ではなく、自社で開発・運用するシステムの脆弱性だったと説明しています。使っていた変換ツールの名前やCVE番号は公表されていません。全ソースコードの点検と重大度の高い問題の修正は、サービス再開前に済ませたとしています。

通信内容のログが無く「流出のおそれは相応に高い」と認定された理由

調査では、データベースへの大量の読み取りと、同じ時間帯に同じサーバーから外部の特定サーバーへの大容量の送信が記録に残っていました。一方、送信した通信の中身を記録したログは無く、何が何件送られたかは直接確認できていません。そのため外部専門機関の認定は「データ流出のおそれは相応に高い」という表現にとどまり、流出範囲は読み取られたデータから推定した値です。再発防止策に、ログの保存期間の延長と、外部へのデータ送信やデータベースへのアクセスを対象とした監視の強化が入っているのはこのためです。

流出した項目の重さ｜認証情報・OCRテキスト・432件の画像

パスワードのハッシュ値・セッションID・X連携トークン

ユーザー情報には、名前、メールアドレス、パスワードのハッシュ値、利用者ID、端末ID、ログインセッションID、連携していた場合のX連携用トークンとGoogle SSOのメールアドレスなどが含まれます。第二報によると、X連携用トークンは単体ではXアカウントへのログインや操作ができず、OAuth連携の認証情報は無効化済みです。第三報は、パスワードそのものではなくハッシュ値であることと一部の認証関連情報の無効化を理由に、流出した認証関連情報だけを使った不正アクセスによる二次被害は起きないとの見方を示しています。セッションIDが漏れたときにサーバー側で全セッションを失効させる実装はセッションハイジャックとは：Cookieが盗まれる5経路と全セッション失効の実装にまとめました。

ただしハッシュ方式は第三報でも公表されていません。OWASPのPassword Storage Cheat Sheetは、Argon2idならメモリ19MiB・反復2回・並列度1、bcryptならwork factor 10以上、PBKDF2-HMAC-SHA256なら60万回以上を推奨値に挙げています。方式が分からない以上、短い文字列や辞書に載る語を使っていた人は、解読されうる前提で扱ってください。サービス側でハッシュ方式を選ぶ基準と旧方式からの移行の実装はbcryptとは：コスト係数・72バイト制限とArgon2idへの移行コードで解説しています。ハッシュとソルトの役割はハッシュ化とはで整理しています。

画像メタデータのOCRテキストと取得元URLの取り消せない性質

画像メタデータには、画像ID（画像URLを構成する情報）、アップロード元IPアドレス、User-Agent、EXIF位置情報、OCRテキスト、画像タイトル、取得元URL、非公開画像のパスフレーズのハッシュ値などが含まれます。OCRテキストは画像に写っていた文字をテキスト化したもので、画面キャプチャなら表示されていた文章がそのまま文字列で残ります。取得元URLには、社内システムを撮っていればホスト名や管理画面のパスが並びます。

133名・432件の画像が閲覧・取得されたことの意味

画像ファイルを大量に取得した記録は見つかっていません。それでも、Helpfeelが外部専門機関の調査結果をもとに追加で調べたところ、133名が保存していた画像432件が第三者に閲覧・取得されていました。対象者には対象画像を明示した個別の連絡が済んでいます。連絡を確認できていなくても、それだけでこの432件の対象外とは判断できません。迷惑メールのフォルダも含めて案内を探し、見当たらなければGyazoの問い合わせ窓口で確認してください。加えて、流出した画像IDから画像URLをたどって閲覧された可能性は完全には否定できないとしており、次の章の棚卸しが必要になるのはこのためです。

利用者の点検手順｜パスワード変更・連携解除・配信再開前の棚卸し

Gyazoとパスワード使い回し先の変更手順

第三報は、本件の発生以降にパスワードを変えていない人に変更を求め、同じか似たパスワードを使う他サービスも変えるよう呼びかけています。使い回していた場合、被害はGyazoの中だけで終わりません。ハッシュが解読されると、攻撃者は復元したメールアドレスとパスワードの組み合わせを他サイトへ順に試します。手口とサービス側の検知指標はパスワードリスト攻撃とは？検知の指標と漏えい照合・レート制限の実装で扱っています。

変更の順番は、パスワード再設定の受け口になるメールアカウント、決済や送金のサービス、クラウドの管理コンソール、SNSです。あわせて二要素認証を有効にすると、パスワードを知られても単独では入れなくなります。方式の違いは二段階認証とはを参照してください。

X連携とGoogle SSOを使っていた場合の見直し

X連携用トークンはHelpfeel側で無効化済みですが、Xの設定にある連携アプリの一覧からGyazoのアクセス権を取り消しておけば、自分の手で確実に切れます。必要なら連携し直すと新しいトークンが発行されます。Google SSOで流出したのはメールアドレスで、Google側の認証情報ではありません。SSOだけを理由にGoogleアカウントのパスワードを変える必要はなく、許可済みアプリの一覧からGyazoを見直せば足ります。ただし、Gyazoと同じか似たパスワードをGoogleアカウントにも使っていた場合は、前の節のとおり変更してください。

配信再開前のスクリーンショットの確認項目

画像メタデータ約4.9億件は主に2019年1月以前のアップロード分なので、古くから使っている人ほど対象に入りやすくなります。設定ページから全件まとめて再開すると、次のような画像も「リンクを知っている全員」などの元の公開範囲へ一斉に戻ります。古い順に見直し、該当するものは停止のままにするか削除してください。

• ログイン画面や設定画面など、IDやURLが写っている画面
• 顧客名や金額が写った管理画面・メール・チャット
• APIキーやトークン文字列が表示された開発画面
• 自宅や勤務先で撮影した写真（EXIF位置情報）

APIキーや鍵が写っていた場合は、発行元で失効させて作り直すしかありません。画像を消しても、流出したOCRテキストは戻らないためです。

業務でGyazoを使っていた企業の確認範囲｜社内URLとOCRテキスト

Gyazoはメールアドレスを登録しなくても使えるため、会社が契約していなくても、従業員がチャットや課題管理での画面共有に個人で使っていた可能性があります。その場合、会社が把握していないアカウントに業務画面が溜まり、そのOCRテキストと取得元URLが流出の対象に入ります。最初に、ブラウザ拡張やデスクトップアプリの導入状況と、チャットに貼られたgyazo.comのURLから、業務で使っていた従業員とアカウントを特定してください。Helpfeel自身も、再発防止策に社内業務での画像共有ツールの利用ルールの見直しを挙げています。

露出した管理画面のURLと鍵への対処

取得元URLに社内ホスト名や管理画面のパス、SaaSのテナント名が並んでいれば、外から見えないはずの構成を推測する材料になります。OCRテキストの社員名や部署名は、標的型メールの精度を上げます。写っていた鍵やトークンは失効させ、外部から届く管理画面には接続元の制限をかけます。痕跡は不正アクセスの調べ方｜ログの確認方法と痕跡を見つけるコマンド例の手順で、9月11日以降の管理画面へのログインと見慣れない接続元から先に抽出してください。

画面共有ツールの利用ルールで決めておく範囲

禁止だけを決めると、代わりに使ってよいツールが示されず、従業員が別の無料ツールを選ぶ余地が残ります。決めるのは、業務画面を置いてよいサービス、個人アカウントでの業務利用の可否、共有した画像の保存期間です。会社契約のサービスに寄せれば、退職時の削除やアクセス権の管理を会社側で行えます。

自社の顧客や取引先の個人データを含む画面をGyazoへ上げていた場合、自社の報告要否も検討が要ります。個人情報保護委員会の案内では、報告対象は要配慮個人情報、財産的被害のおそれ、不正の目的によるおそれ、本人1,000人超の四類型で、速報は概ね3〜5日以内、確報は30日以内（不正の目的によるおそれは60日以内）です。委託や取扱いの実態で判断が変わるため、委員会の相談窓口や専門家に確認してください。起算日や報告事項は個人情報保護委員会への報告義務｜対象4類型・速報3〜5日と確報30日の実務で整理しています。Helpfeel自身は9月15日に速報、9月24日に続報を出し、確報は法令の期限内に提出するとしています。届出電気通信事業者として総務省、約30の国・地域の監督機関にも報告し、京都府警察に相談しています。

アップロード処理を持つサービスの対策｜変換処理の入力・隔離・権限分離

今回の構図は、利用者が中身を決められるファイルを変換するサーバーから、利用者のデータベースまで届いたというものです。アップロード機能を持つサービスなら、入口・隔離・権限の3か所で同じ経路を塞げます。入口の基本はOWASPのFile Upload Cheat Sheetにある、拡張子の許可リスト、Content-Typeを信用しない種別検証、ファイル名の付け直し、サイズ上限、Webルート外への保存です。アップロード先での実行制限は、同時期のPhotoGoodsの不正アクセスとカード情報漏えいでも扱っています。

変換コマンドの引数配列とサーバー側のファイル名生成

Gyazoの変換処理でどのツールが使われていたかは公表されていません。ここでは動画変換でよく使われるFFmpegを例に、コマンドの組み立て方で結果がどう変わるかを示します。

import subprocess
import uuid
from pathlib import Path


def convert_unsafe(filename):
    # 悪い例：利用者が決めたファイル名を文字列のままシェルに渡している
    subprocess.run(f"ffmpeg -loglevel error -i {filename} -y out.mp4", shell=True)


def convert_safe(src: Path, workdir: Path) -> Path:
    # 入出力のファイル名はサーバー側で付け、引数は配列で渡す（シェルを通さない）
    dst = workdir / f"{uuid.uuid4().hex}.mp4"
    subprocess.run(
        ["ffmpeg", "-nostdin", "-loglevel", "error",
         "-i", str(src), "-t", "10", "-c:v", "libx264", "-an", str(dst)],
        check=True, timeout=60,
    )
    return dst


if __name__ == "__main__":
    evil = "in.mp4; touch pwned #"
    convert_unsafe(evil)
    print("unsafe:", "pwned 作成" if Path("pwned").exists() else "pwned なし")
    Path("pwned").unlink(missing_ok=True)

    try:
        convert_safe(Path(evil), Path("."))
    except subprocess.CalledProcessError as e:
        print("safe: ffmpeg が終了コード", e.returncode, "で失敗")
    print("safe:", "pwned 作成" if Path("pwned").exists() else "pwned なし")

    print("正常系:", convert_safe(Path("in.mp4"), Path(".")).name)

macOS上のFFmpeg 9.0.2（evermeet.cxの静的ビルド）とPython 3.12で、ffmpeg -f lavfi -i testsrc2=size=320x240:rate=10 -t 1 in.mp4 で作った1秒のテスト動画を置き、使い捨てのディレクトリで動かした標準出力が次のとおりです（FFmpeg自身のエラー表示は標準エラーに出ます）。生成ファイル名は実行ごとに変わります。

unsafe: pwned 作成
safe: ffmpeg が終了コード 254 で失敗
safe: pwned なし
正常系: 9132dcdfa70840d18e735724141b42d7.mp4

shell=True の版では、ファイル名の ; 以降がシェルに別のコマンドとして解釈され、touch pwned が実行されました。末尾の # は、後ろに続く -y out.mp4 をコメントにして余計なファイルを作らないためのものです。touch の代わりにデータベースへ接続するコマンドを書けば、今回と同じ経路になります。引数を配列で渡す版では、同じ文字列がただのファイル名としてFFmpegに渡り、入力が見つからない失敗で止まります。それでも利用者の付けた名前はそもそもコマンドに入れず、保存時にサーバー側で付けた名前だけを使ってください。- で始まる名前がオプションとして読まれる問題も、これで避けられます。

変換コンテナの外部ネットワーク遮断と実行権限の制限

入力の扱いを直しても、変換ライブラリ自体の脆弱性は残ります。乗っ取られた後の到達範囲を狭めるには、変換処理を使い捨てのコンテナへ切り出し、外部への通信と権限を取り上げます。--network none でもループバックだけは残りますが、他のホストやデータベースへは届きません。次はdocker container runの公式リファレンスにあるオプションで組んだ例です。

docker run --rm \
  --network none \
  --read-only --tmpfs /tmp:rw,size=64m \
  --cap-drop ALL \
  --security-opt no-new-privileges \
  --user 65534:65534 \
  --memory 512m --pids-limit 64 \
  -v /srv/upload/incoming:/in:ro \
  -v /srv/upload/converted:/out \
  image-converter:1.0 \
  python /app/convert.py /in/a1b2c3.bin /out/a1b2c3.png

image-converter:1.0 と /app/convert.py は、変換処理を入れた自前のイメージを想定した名前です。--user 65534:65534 で動かすため、出力先のディレクトリにはUID/GID 65534が書き込める権限を付けておく必要があります（付けないと変換結果を書き出せません）。

同じオプションで python:3.12-slim を起動し（Docker 29.5.2、出力先は書き込み権限を付けたディレクトリ）、中から外部への接続とファイルの書き込みをPythonで試した結果が次の表です。変換処理が乗っ取られても、データベースへの接続も外部への送信もできません。

受付サーバーと利用者DBの権限を分ける判断と見送る場面

今回、変換処理用サーバーからデータベースへ到達できたことが被害を大きくしました。受付と変換のサーバーには利用者テーブルを読む権限を持たせず、変換結果のDB登録は、結果を検証した別のプロセスが行います。DBの接続ユーザーも用途ごとに分け、受付側には画像テーブルへの追加権限だけを与えます。Helpfeelも再発防止策に、内部システム間のアクセス制御の強化と、侵入された場合の被害を最小化する設計の見直しを挙げています。

判断の軸は人数ではなく、入力を処理するプロセスから何に届くかです。動画や画像を外部ツールやパーサーで変換している、または変換するサーバーから利用者DBや認証情報に届くなら、コンテナ分離とDB権限の分離まで入れる価値があります。逆に、受け取ったファイルを変換せず保存するだけで、そのプロセスがDBや機密データへ届かない構成なら、コンテナ分離は後回しにできます。その場合も拡張子とサイズの制限、ライブラリの更新管理は先に固めてください。受付からDBまでの経路を外部に検査してもらう場合は、脆弱性診断・セキュリティ診断で変換処理の入力の扱いと権限の設計を含めて確認できます。

画像メタデータの最小化｜EXIF除去と削除済みデータの保持期間

アップロード時にEXIF位置情報を取り除くPythonコード

保存しない情報は流出しません。次のコードはPillowで画素だけを新しい画像へ写し、メタデータを持ち越さずにPNGで保存します。向きの情報はImageOps.exif_transposeで先に画素へ反映させるため、除去後に画像が横倒しになりません。

from PIL import Image, ImageOps

GPS_IFD = 0x8825

def show_gps(path):
    with Image.open(path) as im:
        gps = im.getexif().get_ifd(GPS_IFD)
        print(path, "GPS:", dict(gps) if gps else "なし")

def reencode_without_metadata(src, dst):
    with Image.open(src) as im:
        im = ImageOps.exif_transpose(im)
        # 透過を持つ画像はRGBA、それ以外はRGBへ変換する（PモードやCMYKをそのままPNGにしない）
        has_alpha = im.mode in ("RGBA", "LA", "PA") or "transparency" in im.info
        im = im.convert("RGBA" if has_alpha else "RGB")
        clean = Image.new(im.mode, im.size)
        clean.paste(im)
        clean.save(dst, format="PNG")

show_gps("in.jpg")
reencode_without_metadata("in.jpg", "out.png")
show_gps("out.png")

Pillow 13.0.0（2026年10月16日公開の最新版）とPython 3.12で動かしました。入力はPillow自身で作ったテスト画像です。GPS情報と向き情報（Orientation=6）を付けた40×20のJPEGは、変換前は緯度経度が表示され、変換後は「なし」になり、20×40に回転して保存されました。透過色を指定したRGB・L・PモードのPNGはRGBAに変わり、透過した画素も透過のままです。変換の行を入れない形（元のモードのまま Image.new(im.mode, ...) へ貼り付ける書き方）では、パレット（Pモード）のPNGは緑の画素が黒になり、CMYKのJPEGは OSError: cannot write mode CMYK as PNG で止まりました。受付処理で例外になると、利用者にはアップロード失敗としか見えません。Pillow 13.0.0はPython 3.11以上が対象で、Python 3.10の環境で版を指定せずに pip install Pillow すると12系が入ります。

OCRテキストと取得元URLを保存する範囲

Gyazoの第一報が挙げた画像メタデータの流出項目には、OCRテキスト・取得元URL・画像タイトル・EXIF位置情報が並んでいます。画像は1枚ずつ開かなければ中身が分かりませんが、これらのテキストはデータベースから一括で読み出せて、キーワードで検索もできます。保存するなら画像本体とは別のストアに置き、受付・変換サーバーからは参照できない権限にします。検索が必須でなければ保存しない、非公開画像のOCRテキストは作らない、一定期間でテキストだけ消す、といった段階も設けられます。

削除済みデータを消すまでの期間を決めておく理由

流出した削除済みメタデータ約1.74億件は、主に2023年2月以前の削除分でした。利用者が消したつもりのデータが3年以上残っていた計算です。第三報によると、Gyazoは画像ファイル本体を削除後一定期間で消す一方、メタデータは不正利用の調査や公的機関からの照会に備えて保持していました。再発防止策として、削除済み画像のメタデータを削除から60日で自動消去するポリシーを策定し、過去分も順次消去、退会ユーザーの操作記録にも保持期間を定め、方針をプライバシーポリシー等で明示するとしています。

自社サービスでも、論理削除の保持期間を決めて物理削除のバッチを定期で回し、バックアップにも同じ期限を適用します。照会対応のために残すなら、残す項目を識別子と日時に絞り、OCRテキストのような中身は残さない設計にしてください。退会者の本人確認書類画像まで残っていた同時期の事例は、タイムズカーの情報漏洩で画像の保存期限の設定例とあわせて扱っています。

よくある質問

Gyazoはこのまま使い続けても安全でしょうか？

原因の脆弱性は9月12日に修正され、全ソースコードの点検と重大度の高い問題の修正を経て9月27日に再開しています。第三報の時点で同じ経路の不正アクセスや二次被害は確認されていません。使い続けるなら、パスワードを変え、過去画像の配信再開は中身を確かめてから選んでください。業務画面の共有に使う場合は、会社として利用範囲を決めてからにしてください。

Gyazoの運営会社はどこですか？

株式会社Helpfeel（本社：京都府京都市）です。2022年10月1日にNota株式会社から社名を変えました（Helpfeelの公式発表）。ナレッジ共有ツールのCosense（旧Scrapbox）とFAQ検索のHelpfeelも提供しています。両サービスはGyazoと異なるシステム構成で運用されており、第三報でも情報漏えいや不正アクセスの痕跡は確認されていません。

メールアドレスを登録していない匿名ユーザーも対象ですか？

対象です。ユーザー情報約2,362万件のうち約1,801万件（約76%）が匿名ユーザーでした。メールアドレスがなくても、端末IDや画像メタデータ、アップロード元IPアドレスは含まれます。メールでの連絡が届かないため、アップロードしてきた画像の内容を自分で振り返り、写っていた鍵や情報の扱いを決めてください。

パスワードはハッシュ化されていたのに、変更が必要ですか？

必要です。Helpfeel自身が、本件の発生以降に変更していない人へ変更を求めています。ハッシュ方式は公表されておらず、解読の難しさが判断できません。Gyazoと同じパスワードを使う他サービスも同時に変えてください。

削除した画像の情報まで流出したのはなぜですか？

Gyazoは削除した画像のファイル本体を一定期間で消す一方、メタデータは不正利用の調査や公的機関からの照会に備えて保持していたためです。主に2023年2月以前の削除分約1.74億件が流出しました。削除済み画像のファイル本体は流出していません。今後は削除から60日でメタデータを自動消去するとしています。

関連記事

• OSコマンドインジェクションとは？仕組みと引数配列で防ぐ実装をPython・Node.js・Goのコード例で解説
• パスワードリスト攻撃とは？検知の指標と漏えい照合・レート制限の実装
• 個人情報保護委員会への報告義務｜対象4類型・速報3〜5日と確報30日の実務
• さくらインターネットの不正アクセスと最大136万件｜管理基盤経由の侵害と利用者の点検手順
• 脆弱性診断とは？種類・費用相場・進め方と外注時の判断基準を解説