セキュリティ Contribute
リソース
Mozilla の HTTP Observatory CLIとQualys SSL Labs Server Testは、潜在的な問題を発見し、セキュリティのベストプラクティスへの準拠を確実にするための良いリソースです。
外部リソースを含む
外部のフォント、CSS、JavaScriptは、Google AnalyticsとMatomoを除いて、インスタンスが有効にしている場合のみ、決して使用しないでください。アセットは常にGitLabインスタンスからローカルにホストされ、提供されるべきです。iframes
経由で埋め込まれたリソースは、iframe
なしでは使えない reCAPTCHA のような特定の状況を除いて、決して使ってはいけません。
インラインスクリプトとスタイルの回避
XSSの脆弱性からユーザーを守るため、将来的にはコンテンツセキュリティポリシーを使用してインラインスクリプトを無効にする予定です。
インラインスクリプトは何かを簡単にする一方で、セキュリティ上の懸念もあります。ユーザーから提供されたコンテンツが意図せずサニタイズされないまま放置されると、悪意のあるユーザーがウェブアプリにスクリプトを注入することができます。
インラインスタイルはほとんどの場合避けるべきで、代替手段が見つからない場合にのみ使用すべきです。これにより、可読性だけでなく、スタイルの再利用が可能になります。
HTML出力のサニタイズ
生のHTMLを出力する必要がある場合は、それをサニタイズする必要があります。
Vueを使用している場合は、v-safe-html
ディレクティブ を使用できます。
その他の使用例については、アイコンのレンダリングも可能なdompurify
の設定済みバージョンをラップしてください:
import { sanitize } from '~/lib/dompurify';
const unsafeHtml = '<some unsafe content ... >';
// ...
element.appendChild(sanitize(unsafeHtml));
このsanitize
関数は、オリジナルと同じ設定を取ります。
セキュリティ問題の修正
古いコードをリファクタリングするとき、まだ関連するかもしれないセキュリティ問題を捕捉するために書かれた仕様を、誤って削除しないようにすることが重要です。
describe
またはit
ブロックのどちらかに、#security
という印を付けて、コードを読んでいるエンジニアに、これらの仕様を削除することは、将来、重大な結果をもたらす可能性があり、セキュリティ問題の再導入を発見する可能性のあるコードを削除していることを伝えるべきです。