Change Details

auth.wikimedia.org has restricted functionality and no user JS, so it doesn't need to support external resources and could just an aggressive CSP (e.g. no eval). Since the XSS threat surface is much smaller than for normal wikis, this is low stakes, but could be an easy-to-implement defense in depth (and also a marginal performance improvement - our standard CSP headers are now at 3K).

auth.wikimedia.org has restricted functionality and no user JS, so it doesn't need to support external resources and could just use an aggressive CSP (e.g. no eval, no external domains other than the canonical domain). Since the XSS threat surface is much smaller than for normal wikis, this is low stakes, but could be an easy-to-implement defense in depth (and also a marginal performance improvement - our standard CSP headers are now at 3K).

auth.wikimedia.org has restricted functionality and no user JS, so it doesn't need to support external resources and could just use an aggressive CSP (e.g. no eval, no evalxternal domains other than the canonical domain). Since the XSS threat surface is much smaller than for normal wikis, this is low stakes, but could be an easy-to-implement defense in depth (and also a marginal performance improvement - our standard CSP headers are now at 3K).