piapia123
ja

security.txt の解析(RFC 9116)

Web

処理はすべてブラウザ内で完結します。データは送信されません

入力
ファイルをここにドロップすると読み込めます
出力

`security.txt` はサイトのルートに置くプレーンテキストで、「脆弱性を見つけたら誰に連絡するか」を研究者に伝えるためのファイルです。これが無いと研究者は推測するしかありません —— `security@` か `abuse@` か、報奨金はあるのか、暗号化した報告を受け取るのか。推測を誤ると、報告がそのまま公開されるか、そもそも誰にも届きません。 文法は「1 行に 1 つ `フィールド: 値`」と単純なので、数行のコードで自前のパーサーを書きたくなります。しかし RFC 9116 で本当に重要なのは2 つの必須要件で、自前のパーサーはまずどちらも検査しません。 · `Expires` は必須で、タイムゾーン付きの RFC 3339 時刻でなければなりません。欠けていれば非準拠です。さらに期限切れのファイルは存在しないものとして扱うと定められています —— ここが厄介で、公開しているつもりの連絡先がとっくに失効しているのに、ファイル自体は何の問題もなく見えます。 · `Contact` も必須で、各項目はプロトコル付きの URL(`mailto:` または `https:`)であるべきです。裸の `security@example.com` は見た目は正常ですが、多くのパーサーがその項目を捨てます。 つまりこのツールの出力はフィールドの一覧ではなく、このファイルに意味があるかどうかの判定です。 ⚠️ 通信は行いません:`https://example.com/.well-known/security.txt` を取りに行ったり、そのメールアドレスが実在するかを確認したりはしません。ファイルはご自身で取得してください —— ブラウザーでその URL を開くか `curl` で取得し、ここに貼り付けてください。

機能

  • ⚠️ 最初の行が結論です:有効/期限切れ/Expires なし/Expires を解釈できない、の 4 通りを色分けして表示
  • Expires が無い・形式が不正なときは、なぜそのファイルが無いのと同じなのかを説明します(単なる文法エラーとして片付けません)
  • Expires にはタイムゾーン(`Z` または `±HH:MM`)を必須にします —— タイムゾーンの無い時刻は定義されておらず、地域によって有効期限の判断が変わります
  • Contact・Policy・Canonical などの値が URL の形でない場合、行番号付きで 1 件ずつ指摘します
  • フィールド名は大文字小文字を区別しません。`#` のコメントは別に一覧し、同じフィールドが複数回現れればすべて保持します(Contact はもともと複数可)
  • 判別できないフィールドも一覧します —— 仕様上それらは無視しなければならないため、名前を打ち間違えてもエラーにならず静かに捨てられます
  • PGP クリア署名に対応:署名ブロックから本文を取り出し、`- ` のエスケープも戻します
  • 左右を揃えた 2 列のレポートで、そのまま全文コピーできます
  • 処理はブラウザー内で完結し、貼り付けた内容は送信されません

使い方

  1. ファイルを取得します:`https://<ドメイン>/.well-known/security.txt` をブラウザーで開きます(古いサイトはルート直下のみの場合があります)
  2. 内容をそのままコピーして入力欄に貼り付けます
  3. まず最初の行の結論を見て、そのあとフィールド一覧を確認します
  4. 問題のある行は行番号で示されるので、そこを直してください

よくある質問

他人の security.txt を取得してくれますか?
いいえ。当サイトは静的サイトでバックエンドがなく、すべてのツールはブラウザー内だけで動きます —— これは「データをブラウザーの外に出さない」という原則の代償です。ファイルを取るには、ブラウザーで `https://ドメイン/.well-known/security.txt` を開くか(プレーンテキストなのでそのまま表示されます)、`curl https://ドメイン/.well-known/security.txt` を実行してください。両方に置いているサイトもありますが、仕様が推奨するのは `/.well-known/` のほうです。
Expires が切れるとどうなりますか?
RFC 9116 では、期限切れのファイルは存在しないものとして扱うと定められています。Expires が必須なのはこのためです:連絡先は変わり、ドメインは持ち主が変わり、チームは解散します。2019 年に書いたファイルが永久に有効だと、研究者はもう関係のないメールボックスに脆弱性を送ってしまうかもしれません —— それはファイルが無いより悪いことです。多くのスキャナーは期限切れのファイルをそのまま飛ばすので、公開しているつもりの連絡先はすでに死んでいる可能性があります。有効期限は 1〜2 年先に設定し、切れる前に更新してください。
Contact にはメールと URL のどちらを書きますか?
どちらもプロトコルが必要です:`mailto:security@example.com` または `https://example.com/report`。裸の `security@example.com` は人には読めますが URI ではないため、パーサーは URI として解釈します —— 多くの実装がこの項目を捨てます。Contact は複数書けます(仕様で認められています)。慣例では優先度の高い順に並べ、たとえば先にフォームの URL、次にメールアドレスを置きます。暗号化した報告を受け付ける場合は `Encryption:` に鍵の URL を書いてください(鍵そのものを貼るのではなく、このフィールドも URI である必要があります)。
フィールド名を打ち間違えてもエラーにならないのはなぜですか?
仕様がそう定めているからです:判別できないフィールドは無視しなければならない。この規則は前方互換性のためのもので、将来 RFC に新しいフィールドが増えても、古いパーサーがそれを知らないという理由でファイル全体を拒否してはいけないのです。代償として、名前の打ち間違い(`Acknowledgment` の s が抜けている、`Preferred-Language` も同様)は一切警告されず、その項目は静かに捨てられます。そこでここでは判別できないフィールド名を一覧に出します —— エラー扱いにはせず、見えるようにするだけです。
「PGP クリア署名」とは何ですか?
仕様は(必須ではなく)推奨として、ファイル全体に PGP のクリアテキスト署名を付けることを勧めています。形式は `-----BEGIN PGP SIGNED MESSAGE-----` で本文を包み、後ろに署名ブロックを付けます。利点は、このファイルが確かにあなたから出たもので、途中で改変されていないことを他者が確認できることです。このツールは署名ブロックから本文を取り出して解析し、クリアテキスト署名の仕様が要求する `- ` のエスケープも戻しますが、署名そのものは検証しません —— 検証には公開鍵が必要で、公開鍵の取得にはネットワークが要ります。検証には `gpg --verify` を使ってください。

関連ツール