Webサービスを公開するときのチェックリスト
catnosecatnose• デザインが好きなソフトウェア・エンジニア• 個人でWebサービスとか作って「ワンチャン当たれば次も好きに作れる」方式で生きてる• X は @catnose99• いぬとねこ飼ってるWebサービスを公開するときのチェックリスト「同じミスは繰り返さないように…」「明日は我が身…」の精神で逐一メモってきたチェックリストの一部を公開します偏りやヌケモレがいっぱいあります
あらかじめご了承くださいその 1

技術以前編

サービス名が他言語でおかしな意味を持ってないこと• 他言語圏の利用者がいる場合はとくに• ChatGPTや wordsense.eu で調べとくと良い• 例: 「かっこいいサービスにしたい！

よし、名前はKackerにしよう！」

売上等の会計処理をどのようにするか担当者と確認が取れているか• どこが売上で何が経費になる？
• 例えば返金が発生した場合はどう扱う？
• 経理担当者にお願いすることになるタスクは？
• 個人開発なら税理士と相談しとくと安心後から「必要なデータが取れてない！」とならないように…

• たとえばStripeを使うならStripeに担当者を（必要最小限の）権限で招待し、会計に必要なデータが揃っているか確認しておく• アプリケーション側で用意すべきデータがあればCSVエクスポート機能等をつけておく法律上の懸念点がないか確認が取れているか• 関連する法律に改正が入っていたりする• とくに決済機能を持つ場合には要注意
特定商取引法、インボイス制度、景品表示法、C2C決済なら資金決済法などなど…

• 個人開発でも弁護士と相談しとくと安心

クローズドチャット機能を提供する場合
電気通信事業者の申請をしていること• サービスに特定のユーザーだけが見れるチャット機能がある場合は要注意• 参考:「個人開発でクローズドなチャットを作るので電気通信事業に届出」•

https://zenn.dev/saikou_kunisaki/articles/3c39a2f83006d4

その 2

セキュリティ編

認証に関わるCookieの属性
http-only属性がtrueになっているか（XSS緩和策）same-site属性はLaxかStrictか（CSRF対策等）
Originヘッダの値を検証する対策等も合わせて検討したい
参考: 令和時代の API 実装のベースプラクティスと CSRF 対策 | blog.jxck.io

secure属性がtrueになっているか（中間者攻撃対策）
HTTPS通信でのみCookieが送られるようにする

認証に関わるCookieの属性
domain属性が適切に設定されているか• Cookieがサブドメインにも送られる設定の場合別サイトに脆弱性があるとインシデントに繋がるかも• Set-CookieでDomain属性を空にするとそのドメインにのみ送られるように• Cookie名の接頭辞を__Host-とするとDomain属性が空になっていないCookieの指定を無視してくれるユーザーの入力値のバリデーション
バリデーションがクライアント側だけでなくサーバー側でも行われているかURLのバリデーションを忘れていないか
プロトコル部分の検証を忘れがち。javascript:から始まる
URLを許可してしまっていないか

SQLインジェクションが可能になっていないかユーザーの入力値のバリデーション
ユーザーの入力値をそのままHTMLとして表示していないか
innerHtmlやdangerousllySetInnerHtml（React）により埋め込まれる文字列をユーザーが自由に指定できるようになっていないかユーザーの入力値のバリデーション
正規表現のバリデーションがバイパスできるようになっていないか
例: 文頭や末尾のチェック漏れなど
参考: 正規表現でのURLのチェックとバイパス | mbsd.jp

ユーザーがURLに含まれるハンドルネーム等を指定できる場合そのバリデーションは十分か
https://x.com/username のような構造の場合は要注意• 他ページのURLと被らないようになっているか
例: /about や /admin など「reserved username」で検索すると良いかも• フレームワークやホスティングサービスにより使われるURLもあるので注意…
例: /404 や /_ah など

データの更新
更新・削除を未認証もしくは権限を持たないユーザーができるようになっていないか
改ざん可能なパラメータを信頼して本人確認をしてしまっていないか（例: userIdを他人の値に変えても更新できてしまう）

SQLのDELETEやUPDATE文でWHEREが適切に設定されているか
例: とあるUserのPostsを一括更新するつもりがwhere句が適切に設定されておらず全Postsが更新されてしまうその他セキュリティ系
退会/メアド変更などの重要な操作は直前のログインを必須にしているか（XSS緩和策）
ユーザーにより内容が変わるレスポンスがCDN等にキャッシュされていないか
オブジェクトストレージのディレクトリページのが意図せず公開されていないか
参考: Cloud Storageでファイルは公開 & 一覧ページは非公開にする - catnoseその他セキュリティ系
クライアントで指定されたURLにバリデーション無でリダイレクトしていないか（オープンリダイレクト対策）
例: https://example.com/login?redirect_to=https://evil.exampleのようにクエリ文字列で渡されたURLにそのまま遷移してしまう

ユーザーから渡された文字列をそのままレスポンスヘッダに含めてしまっていないか
レスポンスヘッダが改ざんされてしまう可能性その他セキュリティ系
ファイルアップロードのバリデーションは十分か
画像の形式のバリデーションは行われているか
例: 悪意のあるスクリプトを含むSVGをアップロードできてしまう等
特にアップロードファイルのURLとアプリケーション本体のURLが同一ドメイン/サブドメインの場合は要注意

各種サービスの設定も確認しておきたい
DBの自動バックアップは有効になっているか
オブジェクトストレージもバックアップしているか
クラウドサービスには二要素認証を設定しているか
余計な権限が付与されていないか
リリース後は使われてなさそうなIAMロールも消すのがこわいその3

メール配信編ユーザーの入力値がメールに含まれる仕様の場合その入力を悪用してスパムメールが送られないか
例: ユーザー名やアイテムのタイトル等の文字列をうまく設定すれば宣伝やスパム的な内容のメールにできてしまう

1ユーザーの操作によりに不特定多数に繰り返しメールが送られないか
例: フォロー機能で1万人をフォローすると1万人に通知メールが送られてしまう

SPF / DKIM / DMARC 関連の設定ができているか
ログイン不要の購読解除リンクは設置されているか
大人数にメルマガを送るサービスの場合、 RFC8058に則った1クリック購読解除に対応しているか（Gmailの規制に関わる）
参考: メール送信者のガイドライン

連続でメール配信タスクが呼び出されたときに同一のメールが二度送信されてしまわないか退会したユーザーにメールが送られてしまわないか休憩用スライド

その4

パフォーマンス編

パフォーマンスが重要なページで余計な再レンダリングが発生していないか※ Reactなどのフロントエンドフレームワークの話

余計なパッケージがクライアントに配信される
JavaScriptにバンドルされてしまっていないか
bundle analyzerなどを使ってチェックする

巨大な画像がそのまま読み込まれていないか
例: 幅400pxで埋め込まれている画像が実は1MBもあった静的ファイルがCDNにキャッシュされているか
Next.jsなどのフレームワークではJSやCSS等の大量の静的ファイルにリクエストが飛ぶ。これら全てがオリジンサーバーから返されないようにしておきたい

画像によるレイアウトシフトが起きないか
widthとheight もしくは aspect-ratio を指定

その5

その他もろもろ編

SEO対策
全ページでtitleタグが適切に指定されているか
エラー関連のページのステータスコードが40xもしくは50xになっているか
メンテナンス中に404になっていたらGoogleがこのページは削除されたのだと認識してしまう可能性
メンテナンス中は503を返すのが良い

SEO対策
検索結果ページにnoindexもしくはcanonical URLが設定されていること
検索キーワードがそのまま<title>に指定される仕様だと検索結果におかしなタイトルでインデックスされてしまうかも

動的に検索結果にインデックスされて欲しいページが生成されるサービスの場合、XMLサイトマップを用意し、Search Consoleに登録していること

複数環境での動作確認
スマホで見たときにUIが崩れないか（ありがち）
ハンドルネームなどのユーザーの入力値が長いときに見た目が崩れないか（ありがち）主要ブラウザで動作確認したか
Cookieをオフにして動作確認したか

複数環境での動作確認
Macで開発しているなら「スクロールバーを常にON」にして表示をチェックしたか
各OSで見たときにフォントがおかしくないかその他
ローカルストレージやhttp-onlyでないCookie等が7日後に消えても問題ないか
最近のiOS Safariでは、ブラウザ上のJavaScriptから保存されたCookieやローカルストレージの内容は7日以上ユーザーが触らないと削除されるって知ってました？

3rd Party Cookieに依存した実装になっていないかその他
robots.txtが配置されているかクローラーへの指示等。記載することがなければなくてもいい

日本語サイトの場合<html lang="ja">になっているか
各フレームワーク、デフォルトで lang="en" がち

サーバーエラーが発生したときにエラーの内容が通知
or 検知できるようになっているかその他
実行されまくるとヤバい処理にはレートリミットが設定されているか
特にAI系のAPIを叩くサービスだと気を付けたい。

404ページ/50xページは悪くない感じになっているか
404の場合はトップページなどに戻る導線が表示されていると親切

Dependabotは有効になっているか/設定されているかその他
ファビコンが設定されているか（意外と忘れがち）apple-touch-icon は設置されているか
iOS Safariがこのファイルを求めてめっちゃリクエストしてくる

OGPの設定はされているか
Google Analytics やCloudflare Web Analytics 等のアクセス解析ツールは導入したか（必要な場合に限る）

他にもいろいろあるけど今日はここまでありがとうございました