google-safe-browsing について
Google Safe Browsing によるサイトの警告を診断・予防し、解除を目指すためのセキュリティスキルです。コード調査よりも、公開ページと Search Console の審査手順に重点を置きます。
主な機能
- 01ドメインの Safe Browsing 状態確認
- 02匿名訪問者に見えるページの確認
- 03ドメインやフォームによる警告の予防
- 04Search Console からの審査申請
活用シーン
- 01ブラウザーによるサイトのブロック確認
- 02警告されたサイトの公開ページ調査
- 03新規サイトの予防策の確認
- 04ページ修正後の審査申請
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ davidondrej/ skills --skill google-safe-browsingインストール後、Claude Code で/google-safe-browsingを入力して読み込まれたか確認します。
詳細
Google Safe Browsing:予防と解決
上流のブロックリストである Google Safe Browsing は、Chrome、Brave、Safari、Firefox、Edge に情報を提供しています。そこでフラグが付くと、すべてのブラウザーで一度にサイトがブロックされます。これは公開されているサイトの分類であり、ハッキングではありません。コードのデバッグから始めないでください。
クイックチェック:サイトにフラグが付いていますか?
# Replace the domain. Check apex AND www — they are scored separately.
curl -s "https://transparencyreport.google.com/transparencyreport/api/v3/safebrowsing/status?site=example.com"
レスポンスは )]}' に続いて [["sb.ssr", STATUS, bool, bool, bool, bool, bool, timestamp_ms, "site"]] です。
STATUS 1+すべてfalse=問題なし。STATUS 2+いずれかがtrue=フラグ付き。ブラウザーの警告画面の文言でカテゴリが分かります。「パスワードを入力させようとしています」=欺瞞的な行為/ソーシャルエンジニアリング、「危険なプログラムをインストールしようとしています」=マルウェアです。
人が読みやすい形式はこちらです:https://transparencyreport.google.com/safe-browsing/search?url=example.com
予防チェックリスト(新しい公開 Web プロジェクトごと)
- ドメインに他社の商標を含めないでください。
youtube-x.com、paypal-tool.ioのようにブランド名とログインフォームを組み合わせると、自動的にフィッシングのフラグが付くほか、商標侵害の申し立てを受けるリスクもあります。所有するドメインのサブドメインを使ってください(tool.yourname.com)。 - クローラーを認証情報入力フォームに誘導しないでください。 匿名ユーザーがアクセスするルート URL には、中立的なランディングページを表示してください。入力欄は設けず、運営者(「X が運営しています」)を明記し、製品が特定のブランドに関係する場合は「[ブランド] とは提携していません」と明示します。ログインページはリンク先に置いてください。
- すべてのドメインで、初日から Search Console を設定してください。 ドメインプロパティを追加し、レジストラで TXT レコードを登録します。Google がユーザーに警告画面を表示する前に通知してくれる唯一の窓口であり、フラグが付いた後に再審査をリクエストするための唯一の手段です。
- 公開 URL には公開サイトを置いてください。 分類システムにとって「内部ツール」という説明は意味をなしません。実際には招待制のツールに、待機リストや登録フォームが残っていないか削除してください。新しいドメインにメール収集フォームがあると、情報を収集するための仕組みに見えます。
- 第三者の立場で確認してください。
curl -sL https://the-domain/を実行し、中立的なコンテンツが表示されること、パスワード欄がないこと、タイトルや見出しに他社ブランドが含まれていないことを確認します。
原因究明の手順(すでにサイトにフラグが付いている場合)
- ルートドメインと www でクイックチェックを実行します。フラグとカテゴリを確認してください。
- 匿名でサイトを取得し(
curl -sL)、Googlebot に表示される内容を正確に確認します。ドメイン名/タイトル/見出しに含まれるブランド名、認証情報入力フォームへの即時リダイレクト、公開メール収集フォーム、ドメインの新しさ(whois)を確認してください。 - Git の履歴はたいてい見当違いです。きっかけは通常、最近のコミットではなく、再クロール/再分類やユーザーからの報告です。スクリプトの埋め込みや依存関係の侵害を除外する場合に限り、履歴をざっと確認してください。
- ユーザーのアップロードやサードパーティーのコンテンツをドメイン上でホストしている場合は、特定のアップロードファイルやページがフラグの原因になっていないか確認します(Search Console にサンプル URL が表示されます)。
復旧
- まず公開されているサイトを修正し(上記のチェックリストを参照)、デプロイします。フィッシングの疑いが残る状態で再審査をリクエストしても却下され、違反を繰り返すと解除までにさらに時間がかかります。
- Search Console でドメインを確認します(レジストラで DNS TXT を設定すると、数分で反映されます)。
- Search Console > セキュリティの問題 > 再審査をリクエスト。サイトの内容、利用者、変更内容について、事実に基づく文章を 1~2 文で記載します。
- 通常、対応には 1~3 日かかります。クイックチェックで
STATUS 1が返るまで再実行し、その後ブラウザーでも確認します。 - ドメイン自体に他者の商標が含まれている場合、フラグが解除されても一時的なものと考えてください。再びフラグが付く可能性が高い状態は変わりません。恒久的な解決策は、中立的なドメインに移行することです。
実例
youtube-alpha.com(2026-07):社内チーム用ツールでしたが、ドメインに「youtube」が含まれ、匿名ユーザーは「YouTube Alpha」とブランド表示されたメールアドレスとパスワードのフォームに直接リダイレクトされていました。また、公開された待機リストフォームもありました。欺瞞的なサイトとしてフラグが付き、Brave/Chrome でブロックされました。修正内容:待機リストのページを削除し、運営者と非提携の告知を記載した中立的な /welcome ランディングページを追加し、ログアウト状態で表示されるすべてのページからブランド表示を削除してから、Search Console で再審査をリクエストしました。問題はコードではありませんでした。