S³ EXTERNAL SCAN
EXTERNAL SECURITY DIAGNOSTICS
/* EXTERNAL_SCAN_INPUT */
// target_url: string — HTTP(S) endpoint to diagnose
診断対象URL
S3_EXTERNAL_SCAN::TERMINAL v1.0
[--:--:--] 診断対象URLを入力して「診断開始」を押してください
/* OVERALL_GRADE */
総合グレード
-
未診断
grade: A|B|C|D|F
/* HEADER_CHECK */
ヘッダー診断
-
passed / total
security_headers: X/Y
/* TECH_DETECT */
技術検出
-
検出項目
fingerprint: server|framework
/* COOKIE_SAFETY */
Cookie安全性
-
安全性スコア
flags: Secure|HttpOnly|SameSite
/* CORS_CHECK */
CORS設定
-
Access-Control
allow-origin|credentials|methods
/* INFO_LEAK */
情報漏洩
-
検出findings
paths: robots|.git|.env|error
Content-Security-Policy

XSS防止の最重要ヘッダー。インラインスクリプトの実行を制御し、許可されたリソースオリジンのみを指定します。

default-src script-src style-src img-src connect-src frame-ancestors

script-src 'self' でインラインスクリプトをブロック。nonceまたはhashベースの許可で安全に個別解放。

X-Frame-Options

クリックジャッキング防止。iframe内でのページ表示を制御します。

DENY 全てのiframe埋め込みを拒否
SAMEORIGIN 同一オリジンのみ許可
ALLOW-FROM 非推奨（CSP frame-ancestors推奨）
X-Content-Type-Options

MIMEスニッフィング防止。ブラウザがContent-Typeを推測して実行することを阻止します。

nosniff を設定することで、text/plainとして配信したファイルがJavaScriptとして実行されるリスクを排除。

Strict-Transport-Security (HSTS)

TLSダウングレード攻撃防止。ブラウザにHTTPS接続のみを強制します。

max-age HSTS有効期間（秒）
includeSubDomains サブドメインにも適用
preload ブラウザ組み込みリストに登録

推奨: max-age=31536000; includeSubDomains; preload

Referrer-Policy

外部遷移時にどこまでのリファラー情報を送信するかを制御します。

no-referrer リファラーを一切送信しない
same-origin 同一オリジンのみ
strict-origin-when-cross-origin 推奨設定
unsafe-url 完全URLを常に送信（非推奨）
Permissions-Policy

ブラウザ機能の制限。ページ・iframe内で利用可能なブラウザAPIを制御します。

camera=() microphone=() geolocation=() payment=() usb=()

=() で完全ブロック、=(self) で同一オリジンのみ許可。

/* HTTP_SECURITY_HEADERS */
// analyze: response.headers → security_posture evaluation
セキュリティヘッダー分析
ヘッダー名 値 評価 推奨設定
🔒
診断結果がここに表示されます
Server header

Apacheバージョン漏洩により、攻撃者が該当バージョンのCVE（既知脆弱性）を特定して標的型攻撃を実行するリスク。

対策: ServerTokens Prod（Apache）、server_tokens off（Nginx）で最小限の情報に制限。

X-Powered-By

フレームワーク情報漏洩。Express, PHP, ASP.NETなどの使用技術が攻撃者に明示されます。

対策: ヘッダー自体を削除する。Express: app.disable('x-powered-by')、PHP: expose_php = Off

Cookie fingerprint

セッションCookie名からサーバーサイド技術を推測できます。

JSESSIONID Java (Tomcat/Spring)
PHPSESSID PHP
ASP.NET_SessionId .NET
connect.sid Node.js (Express)
HTML meta generator

HTMLの <meta name="generator"> タグからCMS（WordPress/Drupal/Joomla等）を検出。

WordPress検出時: /wp-admin/ /wp-login.php など管理画面の存在も確認。バージョン情報と既知脆弱性の突合が可能。

/* TECH_STACK_FINGERPRINT */
// detect: server|framework|cms|language from response artifacts
技術スタック検出結果
検出項目 値 リスク 説明
🔍
診断結果がここに表示されます
Secure flag

HTTPS以外でのCookie送信を防止。HTTP通信ではCookieが平文で送信されるため、中間者攻撃でセッションハイジャックされるリスクがあります。

Secure属性がないCookieは、Wi-Fi盗聴やSSL Stripping攻撃に対して無防備です。

HttpOnly flag

JavaScriptからのCookieアクセスを防止（XSS対策）。document.cookie でセッショントークンを読み取れなくなります。

XSS脆弱性が存在しても、HttpOnlyなCookieはJavaScriptで窃取不可（防御の深層化）。

SameSite

CSRF防止。クロスサイトリクエストでのCookie送信を制御します。

Strict 同一サイトからのリクエストのみ送信
Lax トップレベルナビゲーション時のみ送信（デフォルト）
None 常に送信（Secure必須）
__Host- / __Secure- prefix

Cookie prefix security。特殊プレフィックスによりCookieの属性を強制します。

__Host- Secure + Path=/ + ドメイン指定なし（最強）
__Secure- Secure属性が必須

サブドメインからのCookie上書き攻撃を防止するCookie Fixation対策として有効。

/* COOKIE_SECURITY_AUDIT */
// parse: Set-Cookie headers → flag analysis
Cookie安全性分析
Cookie名 Secure HttpOnly SameSite 評価
🍪
診断結果がここに表示されます
Same-Origin Policy

ブラウザのセキュリティモデル。異なるオリジン（スキーム+ホスト+ポート）間のリソースアクセスをデフォルトで禁止します。

CORSはこの制限を明示的に緩和するための仕組み。サーバーがレスポンスヘッダーで許可するオリジンを指定します。

CORS仕組み

preflight（OPTIONS）リクエストで事前確認後、本リクエストを送信。

Browser → OPTIONS (preflight) → Server → Access-Control-Allow-* → 本リクエスト実行
Access-Control-Allow-Origin Access-Control-Allow-Methods Access-Control-Allow-Headers Access-Control-Allow-Credentials
危険な設定

以下の設定は深刻なセキュリティリスクを引き起こします。

* + credentials ワイルドカード + 認証情報 = 任意サイトから認証済みリクエスト可能
origin reflection Originヘッダーの値をそのまま返す = 事実上のワイルドカード
null origin許可 sandboxed iframe等から攻撃可能
/* CORS_ANALYSIS */
// check: Access-Control-* headers + origin reflection test
CORS設定分析
🌐
診断結果がここに表示されます
robots.txt

機密パスの意図しない開示。Disallow: /admin/ のような記述が、逆に攻撃者に管理画面の存在を教えてしまいます。

robots.txtはアクセス制御ではない（あくまでクローラーへの「お願い」）。認証・認可で保護する必要があります。

.git / .env

ソースコード・環境変数の露出。本番サーバーに/.git/や/.envが公開されている場合、ソースコード全体やDB認証情報が漏洩します。

.git/HEAD リポジトリ存在確認
.git/config リモートURL漏洩
.env DB_PASSWORD, API_KEY等
エラーページ

スタックトレース、バージョン情報がデフォルトエラーページに表示されるケース。Django DEBUG=True、PHP display_errors=On等。

本番環境では必ずカスタムエラーページを設定し、技術的詳細を隠蔽すること。

security.txt

RFC 9116 脆弱性報告の標準。/.well-known/security.txt に連絡先を記載することで、善意のセキュリティ研究者が脆弱性を報告しやすくなります。

Contact: 報告先メール/URL
Expires: 有効期限
Policy: 開示ポリシーURL
/* INFO_LEAK_CHECK */
// probe: common sensitive paths + response analysis
情報漏洩チェック結果
パス ステータス 検出内容 深刻度
🕵
診断結果がここに表示されます
301 vs 302

永続リダイレクト（301）の重要性。HTTP→HTTPSリダイレクトには301（Moved Permanently）を使用すべきです。

301 ブラウザがキャッシュ → 次回以降は直接HTTPSにアクセス
302 キャッシュされない → 毎回HTTPを経由してHTTPSへ（SSL Stripping攻撃に弱い）

302リダイレクトでは、初回アクセス時に中間者攻撃のウィンドウが毎回発生します。

HSTS preload

ブラウザ組み込みリスト。hstspreload.org に登録されたドメインは、ブラウザが最初からHTTPS接続を強制します。

HSTS header設定 → preload申請 → Chrome preloadリスト登録 → 全ブラウザ反映

要件: max-age ≥ 31536000 + includeSubDomains + preload ディレクティブ。

/* HTTPS_REDIRECT_CHAIN */
// trace: HTTP → HTTPS redirect chain + status codes
HTTPSリダイレクトチェーン
🔒
診断結果がここに表示されます