Web サービスの完全 HTTPS 化 - クックパッド開発者ブログ
インフラストラクチャー部長の星 (@kani_b) です。 2017年1月5日をもって、クックパッド における全ページで HTTPS が使われるようになりました。 完全 HTTPS 化をするにあたり、その理由や具体的な進め方について紹介します。 以前 SRE Tech Talks #2 にて一部発表した内容も含みますので、ご興味のある方はあわせてスライドもご覧ください。 完全 HTTPS 化に踏み切った理由 以前のクックパッドは、ログインや登録情報の参照など、いわゆる個人情報や認証情報を扱う箇所のみに HTTPS が使われていました。 このように「必要な箇所にのみ HTTPS を使う」構成は、ある程度歴史のある Web サービスにおいてよく使われている構成です。 この状態から、完全 HTTPS 化に踏み切った理由を説明します。 サービスをよりセキュアにするため HTTPS の利用を考えるに
CSPレポート(Mixed Contentの問題)をGoogle Analyticsに集約する
Content Security Policy(CSP) ではHTTPヘッダや<meta>要素に定義を記述し、さまざまな条件でコンテンツに制約をかけることができます。 そのCSPの中でも実際に制約をかけずにテストして、その結果を特定のURLにPOSTする Content-Security-Policy-Report-Only という仕組みがあります。 CSPにはHTTPSではない画像やJavaScriptを読み込めなくする制約も設定できるので、HTTPからHTTPSに移行する際などに役立ちます。 例えば、リソースはすべてHTTPSから読み込まないと行けないというCSPの設定は次のようにかけます。 実際にこのCSPをHTTPレスポンスヘッダに設定するとCSPに対応しているブラウザは、HTTPSではない画像やJavaScriptなどをブロックします。 実際にブロックされると使えなくなって困るの
CSP Report 収集と実レポートの考察 | blog.jxck.io
Intro このブログで CSP レポートの収集を開始してもうすぐ 1 年になる。 現状、対象ドメイン内で <input> は一切提供しておらず、大半が静的に生成されたページであるが、この条件でも、かなり多くのレポートが集まった。 今回は、収集した実際のレポートを例に、攻撃ではないと思われるレポートとしてどういったものが送られて来たかを中心に、その内容やレポーティングサーバ、 CSP の運用に関する現時点の考察についてまとめる。 収集目的 CSP の基本は、意図しないリソースの読み込みや、 Inline Script の実行を防ぐことにある。 例えば、エスケープ漏れにより XSS が発生し、悪意のある Inline Script が埋め込まれた場合でも、 Inline Script を禁止するポリシーを適用したページでは、その実行はブラウザによって Violation(違反)と判断されブロ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
