web要件定義のヒアリングシートはいくつか見たことはあるが、web 開発に
特化したまともなヒアリングシートを見たことがないので作ってみた。
「サイトの目的は」などの上流部分はあえて省いて、機能・実装にフォーカスしている。
思いつくままに記述してみたが、結果としてはインターネット上の
コマース向けサイトに特化した形になった。
請負時のヒアリングシートと、発注時の要件伝達漏れチェックシートと、
開発時のレビュー観点の元ネタとして使えるといいなぁ。今後気づいた
ところがあれば追記していきます。
●2010/02/24 追加分。
- サイトメンテナンス時のアナウンス要否
- メンテナンスページは「503 Service Temporarily Unavailable」を返すようにし、
検索エンジンにキャッシュされないよう注意する。
●2007/08/23 追加分。
404/403/500 などのエラーページについて
- できる限り ErrorDocument 404 http://example.com/error404.html などの絶対 URL
ではなく、ErrorDocument 404 /error404.html と相対 URL で書く。
参考: ErrorDocumentを絶対URLで書くのはやめようよ
●2007/07/22 追加分。
入力フォームについて。
- 半角のみ・全角のみの場合は、ime-mode の active/inactive を設定する。disabled は
設定しないことをおすすめする (メールアドレスを disabled にしてしまい
日本語ドメインが入力できなくなる、といった事態は避けたい)。現時点
では IE6/IE7 のみ。Firefox はバージョン3で対応予定 →参考
●2007/05/01 追加分。
- ファイル一覧・CVS ディレクトリ・.htaccess・.htpasswd など、見えてはいけないファイルの隠蔽
- ファイル一覧が見えてしまうようなら、とりあえず Options -Indexes。
- さらに DirectoryIndex ディレクティブを適切に設定する。
- CVS/ などの管理用ディレクトリは DirectoryMatch などで deny。
- .ht から始まるファイルは、apache のデフォルト設定で <Files ~ "^\.ht"> されているので
問題ないはずだが、誤って見えてしまっているサイトが結構ある。
●2007/04/22 追加分。
- http://www.exmaple.com と http://exmaple.com のどちらが正式 URL かを明確に決める
- いずれにしても、www あり・なしの両方でアクセス可能なようにする
- たとえば www ありが正式な URL なら、www なしの方は www ありにリダイレクトする
- URL をうろおぼえで入力する人や、印刷された URL を入力する際にwww 有無を
間違えることは結構ある。間違った URL でも、とにかくサイトにたどりつける
ようにはしておく。
- www あり・www なしの両方でサイトが閲覧できるようにはしないこと。両方とも
検索エンジンに拾われると、集客が分散してしまう。必ず片方はリダイレクトする。
----------- ここから ------------
●コンテンツ
- サイト内検索有無
- ランキング系コンテンツの有無
- ランキング生成ロジックは?
- リアルタイムに生成? バッチで生成?
- 管理者がランキングを自由に設定できる必要あり?
- 画像・アイコン有無
- flash の有無
- マウスオーバー用の画像要否
- img 要素の width/height 属性を付ける
- 多種多様な画像サイズが存在し、なおかつ自動で更新されるような場合、
width/height を事前に調べるバッチの要否を検討
- 携帯端末用画像ファイル生成が必要か?
- 端末ごとに、フォーマット・画像サイズに制限がある
- favicon.ico
- IE7 のタブに favicon が表示されるので、忘れずに作成したいところ。
- ヘッダ・フッタ有無/種類数
- ヘッダ・フッタを表示しない例外ページはないか?
- RSS の有無
- 会員規約/利用規約の有無
- 会社概要の有無
- サイトマップの有無
●Web ポリシー
- 想定の回線速度
- 対象ブラウザ
- IE6/IE7/Mozilla/Firefox/Safari/Opera/...
- Javascript 必須でよいか?
- cookie 必須でよいか?
- Javascript/cookie を解さないブラウザがきた場合、入り口ではじくべきか?
- 想定の画面解像度
- ブラウザ左のツールバー・エクスプローラバーの存在を忘れずに
- 画面横幅固定? 可変? 範囲指定? (max-width、min-width)
- 画面横幅固定の場合、センタリング?
- web エンコーディング
- 個人的には EUC-JP だが、使用したい文字によっては UTF-8 もあり。
- 携帯なら実質 Shift_JIS
- 長い文字列 (ユーザが長い文字列や URL を入力した場合の対応)
- Firefox はブロック要素を突き破ってレンダリングしてしまう (CSS の
規格としては誤りではないが、これが原因でデザインが大崩れしたりして
よくモメる)
- 対策その1: css で word-break: break-all; overflow: hidden
(Firefox では長い部分が隠れる。overflow: auto でスクロール
バーを出すのもアリだろう)
- 対策その2: 一定文字数ごとに、wbr 要素・ソフトハイフン (­) の挿入
- 参考: 長い文字列の改行方法 - wbr, ­, css
- 参考: Firefox 3 の修正内容のご紹介 その3 ― URLも改行されるように
- リンクポリシー
- 外部サイトに飛ぶ場合は target="_blank" とする? 同一ウィンドウに表示する?
- ポップアップ
- ポップアップを実装する場合、ブラウザのポップアップブロック機能に邪魔
されないよう気をつける (必然性のある場合のみ実装しよう)
- ボタン押下でポップアップ表示 → ポップアップのウィンドウが背面に隠れる →
再度ボタン押下、とした際、最前面に表示されるようウィンドウを focus() すること。
- 404/403/500 などのエラーページのカスタマイズ要否
- できる限り ErrorDocument 404 http://example.com/error404.html などの絶対 URL
ではなく、ErrorDocument 404 /error404.html と相対 URL で書く。
参考: ErrorDocumentを絶対URLで書くのはやめようよ
- 機種依存文字の有無
- 携帯の場合、絵文字の有無 (キャリアごとに互換性がまったくなく、一から実装すると
かなりしんどい。絵文字ライブラリの購入も検討するとよい)
- Google Analytics 設定要否
- SSL の場合は https の方を読むよう注意
- Google Sitemap 設定要否
●入力フォーム
- 入力補完
- 全角半角自動変換
- 前後の空白・タブの自動除去 (メーラー・Excel からコピペした場合によく空白がつく)
- エラー時の挙動
- Javascript によるチェック要否
- エラー表示方法
- 画面上部にまとめてエラー内容を表示する?
- 各 INPUT 要素の上下にエラー内容を表示する?
- submit ボタン連続押下対策要否
- うっかり連打した場合を考えると、2回目の処理がエラーとなり、
「エラーです」と表示されるのはよろしくない。
- 固定幅フォント
- メールアドレス入力フォームなどは font-family: monospace で固定幅フォントにする
(カンマとドットを判別できない人が多いため)
- 半角のみ・全角のみの場合は、ime-mode の active/inactive を設定する。disabled は
設定しないことをおすすめする (メールアドレスを disabled にしてしまい日本語ドメイン
が入力できなくなる、といった事態は避けたい)。現時点では IE6/IE7 のみ。Firefox は
バージョン3で対応予定 →参考
- モバイルの場合、input 要素に istyle, mode, format 属性を指定
することで全角かな/半角カナ/英字/数字が指定可能。→参考
- input 要素の maxlength は指定しない
- チェックボックス・ラジオボタンには label 要素必須 (わたしの趣味)
- TEXTAREA には wrap="off" 必須 (わたしの趣味)
●メール
- メール送信有無
- 携帯にも配信するか?
- キャリアに SPAM 判定されないための対策が必要。
- 適宜 sleep を入れる?
- 高速配信エンジンを利用する?
- エラーメール対処
- エラーメールが返ってきたら、どうする?
- ヘッダに X-HOGEHOGE-ID: などと独自ヘッダを付け、/etc/aliases 経由で
エラーメールの X-HOGEHOGE-ID を解析するのが好き。
- エラーメールを管理者がチェックする必要があるか?
- メールアドレス形式チェック
- 携帯の場合、「顔文字@docomo.ne.jp」などのメールアドレスが平気で
使用されるので、あまり厳密にチェックしない方がよい。
- 携帯の場合、「.hoge@example.com」など RFC 違反のメールアドレスが
利用可能なため、あまり厳密にチェックしない方がよい。
- Postfix はデフォルトではハイフンから始まるメールアドレス宛に
送信しないことに注意 (RFC 的にはハイフンで始まっても問題ない)。
allow_min_user=yes で送信可能。
- メールのエンコーディング
- ISO-2022-JP が無難だが、半角カナを含む場合は要検討
- UTF-8 で送る場合は、配信先メーラーの対応状況をチェック
- メールマガジン有無
- ユーザごとに異なる文面のメールを送る?
- 冒頭に「○○さん」と顧客名を出す?
- リンク押下を追跡できるよう、メール中の URL に一意なパラメータをつける?
- 配送予約要否 (n日の AM 9:00 から送信開始、など)
- 夜間配送 OK?
- 携帯電話の場合、夜間のメール送信はクレームにつながる
- 1行あたりの文字数
- sendmail だと確か 1000バイトで強制的に改行を入れるはず
- 1行が長い CSV ファイルなどをメールでそのまま送る場合は注意
●CGM
- CGM の有無 (Consumer Generated Media: ユーザ参加型コンテンツ)
- 管理者による投稿内容チェックが必要か?
- 事前チェック? 事後チェック?
- ユーザからの通報機能は必要?
- ブラックリスト方式による自動通報機能は必要?
- ユーザへの警告通知/投稿禁止/強制退会機能の有無
●SEO・SEM
- TITLE 要素
- META タグ
- keywords 有無、動的/静的
- description 有無、動的/静的
- URL 静的化 (foo?a=b&c=d ではなく foo/b/d とする、など)
- ALT 要素
- URL にキーワードを含める?
(Amazon のように、商品名を URL エンコードして URL に埋めたりする?)
- モバイル検索に対応する?
- DoCoMo と au が検索サービスを開始した。モバイルの検索は、今かなりアツい。
●アナウンス
- アナウンスは必要?
- トップページのみ? 全ページに表示する?
- サイトメンテナンス時のアナウンス要否
- 「現在メンテナンス中です」と表示するために、別マシンや別 web サーバを
用意する必要がある?
- メンテナンスページは「503 Service Temporarily Unavailable」を返すようにし、
検索エンジンにキャッシュされないよう注意する。
●業務系
- ユーザ種別 (一般/会員/特別会員/代理店/管理者/スーパーユーザなど)
- 何種類?
- 役割は?
- 利用する場所は? (自宅/社内/営業所/出張先/取引先)
- 認証有無
- パスワード忘れの場合は? リマインダ?
- BASIC/Digest 認証?
- セッション用 cookie 発行?
- ルータによる IP アドレス制限?
- 承認フローが必要な部分は? (上司が承認ボタンを押さないと公開されないなど)
- マスタは?
- どんな種類のマスタがある?
- 部門マスタ/取引先マスタ/担当者マスタ
- 商品マスタ/在庫マスタ
- 郵便番号マスタ
- 銀行マスタ (金融機関コードなど)
- 営業日マスタ
- 商品区分マスタ
- 消費税マスタ
- 和暦マスタ
- マスタは初期設定のみでよい? 自動流通? 管理画面から参照/編集可能?
- Excel・Word・PowerPoint ファイルを生成する必要は?
●広告
- 広告有無 (サイトを広告媒体化する?)
- 予約機能有無 (n日の 0:00 から表示開始、など)
- 会員登録時に、ユーザの属性 (性別/年代/都道府県など) を尋ねておく必要あり?
- ページごとに、表示する広告を変えたい?
- ユーザの属性ごとに表示する広告を変えたい?
- PC/モバイルごとに表示する広告を変えたい?
- ランダム表示あり?
- テキスト広告? 画像広告? flash 広告?
- 表示条件は、期間設定? 表示回数? クリック回数?
- レポート機能有無
- CSV を吐き、Excel で整形してもらう?
●ログ・監視系
- アプリ出力のログ内容は?
- エラー発生時?
- バッチの開始/終了メッセージは?
- 開始/終了の際は、日時と「開始しました」「終了しました」をログに
残そう。実行されていたという記録になるし、実行時間の計測もできる。
- 管理者の操作を記録する?
- ログローテート方針は? 年月日付きのファイル名に出力する?
- ログのフォーマットをかっちり決めてしまおう。おすすめは↓ (grep したときに
わかりやすいように作る)
YYYY/MM/DD HH:MM:SS プログラム名(プロセスID) ステータス ログ内容
例:
2007/03/29 03:52:34 mailsend.pl(7223) INFO 開始しました
2007/03/29 03:52:35 mailsend.pl(7223) INFO 商品発送メール送信。会員ID[2422] オーダID[39273]
2007/03/29 03:52:35 mailsend.pl(7223) ERROR 発送状態ステータス異常。送信スキップ。会員ID[4522] オーダID[32324] ステータス[3]
2007/03/29 03:52:36 mailsend.pl(7223) INFO 終了しました
- 保存期間は?
- 保存対象は?
- アプリ出力のログ
- SMTP サーバ等ミドルウェア出力のログ
- OS 出力のログ
- ディスク容量監視/自動通知
- 負荷監視/自動通知
●インフラ/システム
- 自社内サーバ? ハウジング? レンタルサーバ? 共用サーバ?
- DB 有無
- レプリケーション有無
- トランザクションログ有無
- SSL 有無
- 携帯端末の場合は対応認証局が少ないため、ベリサインにしておくのが無難
- SSL から非 SSL ページの画像や CSS・Javascript などを呼ぶと、IE は警告が出る
(共通ヘッダなどで src="http://example.com/common.css" などと書き、SSL
ページからそのヘッダを使用すると警告のダイアログが表示される)
- RAID 有無
- バックアップ
- タイミング (日次/週次/月次/年次)
- 対象
- プログラム
- データファイル (自動生成される CSV など)
- DB (フルダンプ/トランザクションログ)
- バックアップ先 (自サーバ内/他サーバ/テープ)
- ドメイン取得有無
- サブドメイン設定有無
- cookie 対応
- DNS 設定有無
- http://www.exmaple.com と http://exmaple.com のどちらが正式 URL かを明確に決める
- いずれにしても、www あり・なしの両方でアクセス可能なようにする
- たとえば www ありが正式な URL なら、www なしの方は www ありにリダイレクトする
- URL をうろおぼえで入力する人や、印刷された URL を入力する際にwww 有無を
間違えることは結構ある。間違った URL でも、とにかくサイトにたどりつける
ようにはしておく。
- www あり・www なしの両方でサイトが閲覧できるようにはしないこと。両方とも
検索エンジンに拾われると、集客が分散してしまう。必ず片方はリダイレクトする。
- MX 設定
- au 宛に送信したメールについて、エラーメールを受け取りたい場合は SPF 対応が必要
- 開発環境・テスト環境の有無
- 開発環境・テスト環境・本番環境の 3本立てが望ましい (DB も別)
●セキュリティ
- XSS
- 表示の際に、実体参照化すること
- 実体参照化する文字は < > ' " &
- あらゆる箇所で実体参照化するのを忘れずに。
- input 要素の value 属性内、a 要素の href 属性内、javascript 内、
title 要素、meta タグなどは、実体参照を忘れがち。
- href="hoge?a=b&c=d" は誤り。href="hoge?a=b&c=d" が正しい。
- SQL インジェクション
- あらゆる箇所でバインドを使う
- コマンドインジェクション
- sh を実行させない
- セッション固定化 (Session Fixation)
- CSRF
- パストラバーサル (ファイル名をパラメータで受けてしまい、../../data/hoge.csv などが
漏洩してしまう
- そもそもファイル名をパラメータで受けない。ファイル ID などを受け取り、
ファイルID を元にファイル名を決定するようにする
- ドキュメントルート以下に、できるだけデータファイルを置かない
- 事前に漏れては困るコンテンツがあるか (URL が推測可能になっており、
入試結果発表データなどが漏洩してしまわないか)
- サーバ内にアンチウィルスソフトが必要か
- DB などのパスワード
- ソースファイルに直接記述しない
(.htaccess などの設定ミスでソースが丸見えになっても大丈夫なようにする)
- 設定ファイル化したとしても、ドキュメントルート以下に置かない
(誤って Options +Indexes とした場合、設定ファイルを発見されてしまう)
- apache のバージョン隠蔽 (ServerTokens と ServerSignature の設定)
- 個人的にはどうでもいいと思っているが、脆弱性診断などでは指摘されて
しまうので。
- apache のマニュアルページ
- http://example.com/manual/ で apache のマニュアルが見えてしまうと、
ちょっと恥ずかしい。DocumentRoot は必ず /home/service/www/ などに
変更しよう。
- ファイル一覧・CVS ディレクトリ・.htaccess・.htpasswd など、見えてはいけないファイルの隠蔽
- ファイル一覧が見えてしまうようなら、とりあえず Options -Indexes。
- さらに DirectoryIndex ディレクティブを適切に設定する。
- CVS/ などの管理用ディレクトリは DirectoryMatch などで deny。
- .ht から始まるファイルは、apache のデフォルト設定で <Files ~ "^\.ht"> されているので
問題ないはずだが、誤って見えてしまっているサイトが結構ある。
特化したまともなヒアリングシートを見たことがないので作ってみた。
「サイトの目的は」などの上流部分はあえて省いて、機能・実装にフォーカスしている。
思いつくままに記述してみたが、結果としてはインターネット上の
コマース向けサイトに特化した形になった。
請負時のヒアリングシートと、発注時の要件伝達漏れチェックシートと、
開発時のレビュー観点の元ネタとして使えるといいなぁ。今後気づいた
ところがあれば追記していきます。
●2010/02/24 追加分。
- サイトメンテナンス時のアナウンス要否
- メンテナンスページは「503 Service Temporarily Unavailable」を返すようにし、
検索エンジンにキャッシュされないよう注意する。
●2007/08/23 追加分。
404/403/500 などのエラーページについて
- できる限り ErrorDocument 404 http://example.com/error404.html などの絶対 URL
ではなく、ErrorDocument 404 /error404.html と相対 URL で書く。
参考: ErrorDocumentを絶対URLで書くのはやめようよ
●2007/07/22 追加分。
入力フォームについて。
- 半角のみ・全角のみの場合は、ime-mode の active/inactive を設定する。disabled は
設定しないことをおすすめする (メールアドレスを disabled にしてしまい
日本語ドメインが入力できなくなる、といった事態は避けたい)。現時点
では IE6/IE7 のみ。Firefox はバージョン3で対応予定 →参考
●2007/05/01 追加分。
- ファイル一覧・CVS ディレクトリ・.htaccess・.htpasswd など、見えてはいけないファイルの隠蔽
- ファイル一覧が見えてしまうようなら、とりあえず Options -Indexes。
- さらに DirectoryIndex ディレクティブを適切に設定する。
- CVS/ などの管理用ディレクトリは DirectoryMatch などで deny。
- .ht から始まるファイルは、apache のデフォルト設定で <Files ~ "^\.ht"> されているので
問題ないはずだが、誤って見えてしまっているサイトが結構ある。
●2007/04/22 追加分。
- http://www.exmaple.com と http://exmaple.com のどちらが正式 URL かを明確に決める
- いずれにしても、www あり・なしの両方でアクセス可能なようにする
- たとえば www ありが正式な URL なら、www なしの方は www ありにリダイレクトする
- URL をうろおぼえで入力する人や、印刷された URL を入力する際にwww 有無を
間違えることは結構ある。間違った URL でも、とにかくサイトにたどりつける
ようにはしておく。
- www あり・www なしの両方でサイトが閲覧できるようにはしないこと。両方とも
検索エンジンに拾われると、集客が分散してしまう。必ず片方はリダイレクトする。
----------- ここから ------------
●コンテンツ
- サイト内検索有無
- ランキング系コンテンツの有無
- ランキング生成ロジックは?
- リアルタイムに生成? バッチで生成?
- 管理者がランキングを自由に設定できる必要あり?
- 画像・アイコン有無
- flash の有無
- マウスオーバー用の画像要否
- img 要素の width/height 属性を付ける
- 多種多様な画像サイズが存在し、なおかつ自動で更新されるような場合、
width/height を事前に調べるバッチの要否を検討
- 携帯端末用画像ファイル生成が必要か?
- 端末ごとに、フォーマット・画像サイズに制限がある
- favicon.ico
- IE7 のタブに favicon が表示されるので、忘れずに作成したいところ。
- ヘッダ・フッタ有無/種類数
- ヘッダ・フッタを表示しない例外ページはないか?
- RSS の有無
- 会員規約/利用規約の有無
- 会社概要の有無
- サイトマップの有無
●Web ポリシー
- 想定の回線速度
- 対象ブラウザ
- IE6/IE7/Mozilla/Firefox/Safari/Opera/...
- Javascript 必須でよいか?
- cookie 必須でよいか?
- Javascript/cookie を解さないブラウザがきた場合、入り口ではじくべきか?
- 想定の画面解像度
- ブラウザ左のツールバー・エクスプローラバーの存在を忘れずに
- 画面横幅固定? 可変? 範囲指定? (max-width、min-width)
- 画面横幅固定の場合、センタリング?
- web エンコーディング
- 個人的には EUC-JP だが、使用したい文字によっては UTF-8 もあり。
- 携帯なら実質 Shift_JIS
- 長い文字列 (ユーザが長い文字列や URL を入力した場合の対応)
- Firefox はブロック要素を突き破ってレンダリングしてしまう (CSS の
規格としては誤りではないが、これが原因でデザインが大崩れしたりして
よくモメる)
- 対策その1: css で word-break: break-all; overflow: hidden
(Firefox では長い部分が隠れる。overflow: auto でスクロール
バーを出すのもアリだろう)
- 対策その2: 一定文字数ごとに、wbr 要素・ソフトハイフン (­) の挿入
- 参考: 長い文字列の改行方法 - wbr, ­, css
- 参考: Firefox 3 の修正内容のご紹介 その3 ― URLも改行されるように
- リンクポリシー
- 外部サイトに飛ぶ場合は target="_blank" とする? 同一ウィンドウに表示する?
- ポップアップ
- ポップアップを実装する場合、ブラウザのポップアップブロック機能に邪魔
されないよう気をつける (必然性のある場合のみ実装しよう)
- ボタン押下でポップアップ表示 → ポップアップのウィンドウが背面に隠れる →
再度ボタン押下、とした際、最前面に表示されるようウィンドウを focus() すること。
- 404/403/500 などのエラーページのカスタマイズ要否
- できる限り ErrorDocument 404 http://example.com/error404.html などの絶対 URL
ではなく、ErrorDocument 404 /error404.html と相対 URL で書く。
参考: ErrorDocumentを絶対URLで書くのはやめようよ
- 機種依存文字の有無
- 携帯の場合、絵文字の有無 (キャリアごとに互換性がまったくなく、一から実装すると
かなりしんどい。絵文字ライブラリの購入も検討するとよい)
- Google Analytics 設定要否
- SSL の場合は https の方を読むよう注意
- Google Sitemap 設定要否
●入力フォーム
- 入力補完
- 全角半角自動変換
- 前後の空白・タブの自動除去 (メーラー・Excel からコピペした場合によく空白がつく)
- エラー時の挙動
- Javascript によるチェック要否
- エラー表示方法
- 画面上部にまとめてエラー内容を表示する?
- 各 INPUT 要素の上下にエラー内容を表示する?
- submit ボタン連続押下対策要否
- うっかり連打した場合を考えると、2回目の処理がエラーとなり、
「エラーです」と表示されるのはよろしくない。
- 固定幅フォント
- メールアドレス入力フォームなどは font-family: monospace で固定幅フォントにする
(カンマとドットを判別できない人が多いため)
- 半角のみ・全角のみの場合は、ime-mode の active/inactive を設定する。disabled は
設定しないことをおすすめする (メールアドレスを disabled にしてしまい日本語ドメイン
が入力できなくなる、といった事態は避けたい)。現時点では IE6/IE7 のみ。Firefox は
バージョン3で対応予定 →参考
- モバイルの場合、input 要素に istyle, mode, format 属性を指定
することで全角かな/半角カナ/英字/数字が指定可能。→参考
- input 要素の maxlength は指定しない
- チェックボックス・ラジオボタンには label 要素必須 (わたしの趣味)
- TEXTAREA には wrap="off" 必須 (わたしの趣味)
●メール
- メール送信有無
- 携帯にも配信するか?
- キャリアに SPAM 判定されないための対策が必要。
- 適宜 sleep を入れる?
- 高速配信エンジンを利用する?
- エラーメール対処
- エラーメールが返ってきたら、どうする?
- ヘッダに X-HOGEHOGE-ID: などと独自ヘッダを付け、/etc/aliases 経由で
エラーメールの X-HOGEHOGE-ID を解析するのが好き。
- エラーメールを管理者がチェックする必要があるか?
- メールアドレス形式チェック
- 携帯の場合、「顔文字@docomo.ne.jp」などのメールアドレスが平気で
使用されるので、あまり厳密にチェックしない方がよい。
- 携帯の場合、「.hoge@example.com」など RFC 違反のメールアドレスが
利用可能なため、あまり厳密にチェックしない方がよい。
- Postfix はデフォルトではハイフンから始まるメールアドレス宛に
送信しないことに注意 (RFC 的にはハイフンで始まっても問題ない)。
allow_min_user=yes で送信可能。
- メールのエンコーディング
- ISO-2022-JP が無難だが、半角カナを含む場合は要検討
- UTF-8 で送る場合は、配信先メーラーの対応状況をチェック
- メールマガジン有無
- ユーザごとに異なる文面のメールを送る?
- 冒頭に「○○さん」と顧客名を出す?
- リンク押下を追跡できるよう、メール中の URL に一意なパラメータをつける?
- 配送予約要否 (n日の AM 9:00 から送信開始、など)
- 夜間配送 OK?
- 携帯電話の場合、夜間のメール送信はクレームにつながる
- 1行あたりの文字数
- sendmail だと確か 1000バイトで強制的に改行を入れるはず
- 1行が長い CSV ファイルなどをメールでそのまま送る場合は注意
●CGM
- CGM の有無 (Consumer Generated Media: ユーザ参加型コンテンツ)
- 管理者による投稿内容チェックが必要か?
- 事前チェック? 事後チェック?
- ユーザからの通報機能は必要?
- ブラックリスト方式による自動通報機能は必要?
- ユーザへの警告通知/投稿禁止/強制退会機能の有無
●SEO・SEM
- TITLE 要素
- META タグ
- keywords 有無、動的/静的
- description 有無、動的/静的
- URL 静的化 (foo?a=b&c=d ではなく foo/b/d とする、など)
- ALT 要素
- URL にキーワードを含める?
(Amazon のように、商品名を URL エンコードして URL に埋めたりする?)
- モバイル検索に対応する?
- DoCoMo と au が検索サービスを開始した。モバイルの検索は、今かなりアツい。
●アナウンス
- アナウンスは必要?
- トップページのみ? 全ページに表示する?
- サイトメンテナンス時のアナウンス要否
- 「現在メンテナンス中です」と表示するために、別マシンや別 web サーバを
用意する必要がある?
- メンテナンスページは「503 Service Temporarily Unavailable」を返すようにし、
検索エンジンにキャッシュされないよう注意する。
●業務系
- ユーザ種別 (一般/会員/特別会員/代理店/管理者/スーパーユーザなど)
- 何種類?
- 役割は?
- 利用する場所は? (自宅/社内/営業所/出張先/取引先)
- 認証有無
- パスワード忘れの場合は? リマインダ?
- BASIC/Digest 認証?
- セッション用 cookie 発行?
- ルータによる IP アドレス制限?
- 承認フローが必要な部分は? (上司が承認ボタンを押さないと公開されないなど)
- マスタは?
- どんな種類のマスタがある?
- 部門マスタ/取引先マスタ/担当者マスタ
- 商品マスタ/在庫マスタ
- 郵便番号マスタ
- 銀行マスタ (金融機関コードなど)
- 営業日マスタ
- 商品区分マスタ
- 消費税マスタ
- 和暦マスタ
- マスタは初期設定のみでよい? 自動流通? 管理画面から参照/編集可能?
- Excel・Word・PowerPoint ファイルを生成する必要は?
●広告
- 広告有無 (サイトを広告媒体化する?)
- 予約機能有無 (n日の 0:00 から表示開始、など)
- 会員登録時に、ユーザの属性 (性別/年代/都道府県など) を尋ねておく必要あり?
- ページごとに、表示する広告を変えたい?
- ユーザの属性ごとに表示する広告を変えたい?
- PC/モバイルごとに表示する広告を変えたい?
- ランダム表示あり?
- テキスト広告? 画像広告? flash 広告?
- 表示条件は、期間設定? 表示回数? クリック回数?
- レポート機能有無
- CSV を吐き、Excel で整形してもらう?
●ログ・監視系
- アプリ出力のログ内容は?
- エラー発生時?
- バッチの開始/終了メッセージは?
- 開始/終了の際は、日時と「開始しました」「終了しました」をログに
残そう。実行されていたという記録になるし、実行時間の計測もできる。
- 管理者の操作を記録する?
- ログローテート方針は? 年月日付きのファイル名に出力する?
- ログのフォーマットをかっちり決めてしまおう。おすすめは↓ (grep したときに
わかりやすいように作る)
YYYY/MM/DD HH:MM:SS プログラム名(プロセスID) ステータス ログ内容
例:
2007/03/29 03:52:34 mailsend.pl(7223) INFO 開始しました
2007/03/29 03:52:35 mailsend.pl(7223) INFO 商品発送メール送信。会員ID[2422] オーダID[39273]
2007/03/29 03:52:35 mailsend.pl(7223) ERROR 発送状態ステータス異常。送信スキップ。会員ID[4522] オーダID[32324] ステータス[3]
2007/03/29 03:52:36 mailsend.pl(7223) INFO 終了しました
- 保存期間は?
- 保存対象は?
- アプリ出力のログ
- SMTP サーバ等ミドルウェア出力のログ
- OS 出力のログ
- ディスク容量監視/自動通知
- 負荷監視/自動通知
●インフラ/システム
- 自社内サーバ? ハウジング? レンタルサーバ? 共用サーバ?
- DB 有無
- レプリケーション有無
- トランザクションログ有無
- SSL 有無
- 携帯端末の場合は対応認証局が少ないため、ベリサインにしておくのが無難
- SSL から非 SSL ページの画像や CSS・Javascript などを呼ぶと、IE は警告が出る
(共通ヘッダなどで src="http://example.com/common.css" などと書き、SSL
ページからそのヘッダを使用すると警告のダイアログが表示される)
- RAID 有無
- バックアップ
- タイミング (日次/週次/月次/年次)
- 対象
- プログラム
- データファイル (自動生成される CSV など)
- DB (フルダンプ/トランザクションログ)
- バックアップ先 (自サーバ内/他サーバ/テープ)
- ドメイン取得有無
- サブドメイン設定有無
- cookie 対応
- DNS 設定有無
- http://www.exmaple.com と http://exmaple.com のどちらが正式 URL かを明確に決める
- いずれにしても、www あり・なしの両方でアクセス可能なようにする
- たとえば www ありが正式な URL なら、www なしの方は www ありにリダイレクトする
- URL をうろおぼえで入力する人や、印刷された URL を入力する際にwww 有無を
間違えることは結構ある。間違った URL でも、とにかくサイトにたどりつける
ようにはしておく。
- www あり・www なしの両方でサイトが閲覧できるようにはしないこと。両方とも
検索エンジンに拾われると、集客が分散してしまう。必ず片方はリダイレクトする。
- MX 設定
- au 宛に送信したメールについて、エラーメールを受け取りたい場合は SPF 対応が必要
- 開発環境・テスト環境の有無
- 開発環境・テスト環境・本番環境の 3本立てが望ましい (DB も別)
●セキュリティ
- XSS
- 表示の際に、実体参照化すること
- 実体参照化する文字は < > ' " &
- あらゆる箇所で実体参照化するのを忘れずに。
- input 要素の value 属性内、a 要素の href 属性内、javascript 内、
title 要素、meta タグなどは、実体参照を忘れがち。
- href="hoge?a=b&c=d" は誤り。href="hoge?a=b&c=d" が正しい。
- SQL インジェクション
- あらゆる箇所でバインドを使う
- コマンドインジェクション
- sh を実行させない
- セッション固定化 (Session Fixation)
- CSRF
- パストラバーサル (ファイル名をパラメータで受けてしまい、../../data/hoge.csv などが
漏洩してしまう
- そもそもファイル名をパラメータで受けない。ファイル ID などを受け取り、
ファイルID を元にファイル名を決定するようにする
- ドキュメントルート以下に、できるだけデータファイルを置かない
- 事前に漏れては困るコンテンツがあるか (URL が推測可能になっており、
入試結果発表データなどが漏洩してしまわないか)
- サーバ内にアンチウィルスソフトが必要か
- DB などのパスワード
- ソースファイルに直接記述しない
(.htaccess などの設定ミスでソースが丸見えになっても大丈夫なようにする)
- 設定ファイル化したとしても、ドキュメントルート以下に置かない
(誤って Options +Indexes とした場合、設定ファイルを発見されてしまう)
- apache のバージョン隠蔽 (ServerTokens と ServerSignature の設定)
- 個人的にはどうでもいいと思っているが、脆弱性診断などでは指摘されて
しまうので。
- apache のマニュアルページ
- http://example.com/manual/ で apache のマニュアルが見えてしまうと、
ちょっと恥ずかしい。DocumentRoot は必ず /home/service/www/ などに
変更しよう。
- ファイル一覧・CVS ディレクトリ・.htaccess・.htpasswd など、見えてはいけないファイルの隠蔽
- ファイル一覧が見えてしまうようなら、とりあえず Options -Indexes。
- さらに DirectoryIndex ディレクティブを適切に設定する。
- CVS/ などの管理用ディレクトリは DirectoryMatch などで deny。
- .ht から始まるファイルは、apache のデフォルト設定で <Files ~ "^\.ht"> されているので
問題ないはずだが、誤って見えてしまっているサイトが結構ある。
スポンサーサイト
0
1
