The Content Security Policy standard lets you define a list of the inline scripts, inline stylesheets, and subresources that your page permits to load. You can define a content security policy on each page to restrict the capabilities that an attacker would have should a content injection vulnerability exist on the page. If your page displays user-generated content (e.g. a user profile page that r
Fixing mixed content Stay organized with collections Save and categorize content based on your preferences. Supporting HTTPS for your website is an important step to protecting your site and your users from attack, but mixed content can render that protection useless. Increasingly insecure mixed content will be blocked by browsers, as explained in What is mixed content? In this guide we will demon
unsafe-dynamicは'strict-dynamic'という別ディレクティブとなりました (20160622) Content Security Policy Level 3のFirst Public Working Draftが1月に公開されました。 以前「まもなく公開される CSP Level3 の変更点」この記事で書いたように、CSP level 2から幾つかの変更点がありました。 また、メーリングリスト上では議論は続いており、Githubのリポジトリ( https://w3c.github.io/webappsec-csp/ )では編集が続いています。 その中で、「unsafe-dynamic」と「unsafe-hash-attributes」について軽くメモ書き。 unsafe-dynamic unsafe-dynamicキーワードは、インラインスクリプトを許可するuns
EngineeringSecurityGitHub’s CSP journeyWe shipped subresource integrity a few months back to reduce the risk of a compromised CDN serving malicious JavaScript. That is a big win, but does not address related content… We shipped subresource integrity a few months back to reduce the risk of a compromised CDN serving malicious JavaScript. That is a big win, but does not address related content inject
Intro 本サイトにて Content Security Policy を有効化した。 まずは Report Only にて導入し、段階的にポリシーとコンテンツを修正していく方針をとる。 CSP Report については、 report-uri.io を用いて収集することにした。 導入に必要な設定や、注意点についてまとめる。 Content Security Policy Content Security Policy(CSP) とは、 Web におけるセキュリティを向上させる非常に強力な仕組みである。 Content Security Policy Level 2 draft-gondrom-websec-csp-header-00 - HTTP Header Content Security Policy 具体的には、コンテンツに対し Content-Security-Policy
CPP: A Standardized Alternative to AMP February 24, 2016 # AMP performance standards It’s no secret that I have reservations about Google’s AMP project in its current form. I do want to make it clear, though, that what bothers me has never been the technical side of things—AMP as a performance framework. The community working on AMP is doing good work to make a performant baseline. As with any fra
The add-ons team recently completed work to enable Content Security Policy (CSP) on addons.mozilla.org (AMO). This article is intended to cover the basics of implementing CSP, as well as highlighting some of the issues that we ran into implementing CSP on AMO. What is Content Security Policy? Content Security Policy (CSP) is a security standard introduced to help prevent cross-site scripting (XSS)
This version: https://www.w3.org/TR/2024/WD-CSP3-20240618/ Latest published version: https://www.w3.org/TR/CSP3/ Editor's Draft: https://w3c.github.io/webappsec-csp/ Previous Versions: https://www.w3.org/TR/2024/WD-CSP3-20240613/ History: https://www.w3.org/standards/history/CSP3/ Feedback: public-webappsec@w3.org with subject line “[CSP3] … message topic …” (archives) Github Editors: Mike West (G
Content Security Policy Level 3のFirst Public Working Draftがそろそろ公開されそうです。 W3Cのgithubリポジトリより公開予定の仕様が確認できます。 https://w3c.github.io/webappsec-csp/published/FPWD-2015-01.html CSP2からの変更点 CSP3では主に以下の点が変更されたようです( https://w3c.github.io/webappsec-csp/published/FPWD-2015-01.html#changes-from-level-2 )。 1. FETCHの仕様の用語で一から書きなおされました。これにより、CSPの要求と制限が他の仕様と整合性が取れるようになりました(特にService Workersの仕様)。 2. CSP Level2で非推奨とな
Webセキュリティを考える上で大事な仕組みの一つに、Same-Origin Policyという仕組みがあります。 Originは「スキーム・ホスト・ポート」の組み合わせです。これらが一緒であれば、同一Originでありリソースへアクセスすることができます。 歴史的経緯や様々な理由により複数のアプリケーションが同一Originで提供されている場合があります。 たとえば、"チャット"や"ショッピング"の機能が以下の様なURLで提供されているような場合です。 https://example.com/chat/ https://example.com/shopping/ 実際、Googleの検索サービスと地図サービスは同一Originで提供されています。昔からあるリンクや、パフォーマンス、ブランディングのためのようです。 https://www.google.com https://www.goo
フロントエンド周りの技術は驚異的なスピードで進化し、また多様化しています。それらを全てマスターするのは途方もなく大変なので、ペパボでは、社内のエンジニア・デザイナが「最低限これだけはおさえておこう」というスタンダードを文書化することにいたしました。社内向けを想定した文書ではありますが、社内のみに留めず多くの方に役立てたいと考えたため公開します。 スタイルシートの夢 (1) 予測しやすい (2) 再利用しやすい (3) 保守しやすい (4) 拡張しやすい 代表的な CSS 設計手法 既存プロジェクトの CSS に立ち向かう! (0) 流れ (1) 既存の CSS ファイルを元に SCSS ファイルに変換する (2) イニシャライズ CSS や共通の箇所のスタイルを分離する (3) CSSLint を使って、修正しやすいところから整理していく (4) コンパイル (5) スタイルのスコープ(あ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く