debian-mirror-gitlab/doc/development/fe_guide/security.md
2021-02-22 17:27:13 +05:30

4.5 KiB
Raw Blame History

stage group info
none unassigned To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments

Security

Resources

Mozillas HTTP Observatory CLI and the Qualys SSL Labs Server Test are good resources for finding potential problems and ensuring compliance with security best practices.

Including external resources

External fonts, CSS, and JavaScript should never be used with the exception of Google Analytics and Matomo - and only when the instance has enabled it. Assets should always be hosted and served locally from the GitLab instance. Embedded resources via iframes should never be used except in certain circumstances such as with reCAPTCHA, which cannot be used without an iframe.

Avoiding inline scripts and styles

In order to protect users from XSS vulnerabilities, we intend to disable inline scripts in the future using Content Security Policy.

While inline scripts can be useful, they're also a security concern. If user-supplied content is unintentionally left un-sanitized, malicious users can inject scripts into the web app.

Inline styles should be avoided in almost all cases, they should only be used when no alternatives can be found. This allows reusability of styles as well as readability.

Sanitize HTML output

If you need to output raw HTML, you should sanitize it.

If you are using Vue, you can use thev-safe-html directive from GitLab UI.

For other use cases, wrap a preconfigured version of dompurify that also allows the icons to be rendered:

import { sanitize } from '~/lib/dompurify';

const unsafeHtml = '<some unsafe content ... >';

// ...

element.appendChild(sanitize(unsafeHtml));

This sanitize function takes the same configuration as the original.