Hi All, Below is a proposal to increase our websecurity for *.archlinux.org # Goal Better security through Content Security Policy and other headers. # How Either sending CSP headers via nginx or modifying the web application to send the correct headers. Configuring via nginx is probably the easiest way to distribute these changes. # Which sites bugs.archlinux.org bbs.archlinux.org wiki.archlinux.org git.archlinux.org pkgbuild.com pkgbuild.com/~* mailman.archlinux.org kanboard.archlinux.org planet.archlinux.org archlinux.org (django) aur.archlinux.org Excluded is security.archlinux.org, which already includes all of the below headers via flask-talisman. # Which headers ## X-XSS-Protection The HTTP X-XSS-Protection response header is a feature of Internet Explorer, Chrome and Safari that stops pages from loading when they detect reflected cross-site scripting (XSS) attacks. This is mostly superseded by CSP, but still is not harmfull to add. add_header X-Xss-Protection "1; mode=block" always; ## X-Content-Type-Options The X-Content-Type-Options response HTTP header is a marker used by the server to indicate that the MIME types advertised in the Content-Type headers should not be changed and be followed. Check bugtracker/archweb if this breaks attachments or other files which are download. add_header X-Content-Type-Options "nosniff" always; ## X-Frame-Options The X-Frame-Options HTTP response header can be used to indicate whether or not a browser should be allowed to render a page in a <frame>, <iframe> or <object> . Sites can use this to avoid clickjacking attacks, by ensuring that their content is not embedded into other sites. I don't believe we want to allow embedding our websites. add_header X-Frame-Options "SAMEORIGIN" always; ## Content-Security-Policy The HTTP Content-Security-Policy response header allows web site administrators to control resources the user agent is allowed to load for a given page. With a few exceptions, policies mostly involve specifying server origins and script endpoints. This helps guard against cross-site scripting attacks (XSS). This might differ a bit per site, Archweb for example requires unsafe-inline / unsafe-eval for JavaScript and CSS. But all our loaded content should be from the same origin and restricted. An example policy would be: add_header Content-Security-Policy "default-src 'self'; style-src 'self'; font-src 'self'; form-action 'self';" # Challenges * inline JavaScript => archweb/aurweb => use a nonce or rewrite. * inline CSS => archweb/aurweb => use a nonce or rewrite. * unsafe-eval => this should never be allowed and should be fixed # Verifying The following website nicely shows the enabled security headers. https://securityheaders.com/ More information about these headers can be found here. https://scotthelme.co.uk/hardening-your-http-response-headers/ -- Jelle van der Waa