리소스#

Mozilla의 HTTP Observatory CLI와 Qualys SSL Labs 서버 테스트는 잠재적인 문제를 발견하고 보안 모범 사례 준수를 보장하는 데 유용한 리소스입니다.

외부 리소스 포함#

외부 폰트, CSS, JavaScript는 Google Analytics 및 Matomo를 제외하고는 절대 사용해서는 안 됩니다. 이 예외는 인스턴스에서 해당 기능이 활성화된 경우에만 적용됩니다. 에셋은 항상 GitLab 인스턴스에서 로컬로 호스팅되고 제공되어야 합니다. iframes를 통해 임베드된 리소스는 reCAPTCHA와 같이 iframe 없이는 사용할 수 없는 특정 상황을 제외하고는 절대 사용해서는 안 됩니다.

인라인 스크립트 및 스타일 방지#

XSS 취약점으로부터 사용자를 보호하기 위해, 향후 Content Security Policy를 사용하여 인라인 스크립트를 비활성화할 예정입니다.

인라인 스크립트는 작업을 쉽게 만들 수 있지만, 보안 위협이기도 합니다. 만약 사용자가 제공한 콘텐츠가 의도치 않게 새니타이징되지 않은 상태로 남겨지면, 악의적인 사용자가 웹 앱에 스크립트를 주입할 수 있습니다.

인라인 스타일은 거의 모든 경우에 피해야 하며, 대안을 찾을 수 없을 때만 사용해야 합니다. 이를 통해 스타일의 재사용성과 가독성을 높일 수 있습니다.

HTML 출력 새니타이징#

원시 HTML을 출력해야 하는 경우, 반드시 새니타이징해야 합니다.

Vue를 사용하는 경우, v-safe-html 디렉티브를 사용할 수 있습니다.

다른 사용 사례의 경우, 아이콘 렌더링도 허용하는 사전 구성된 dompurify 래퍼를 사용하세요:

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

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

// ...

element.appendChild(sanitize(unsafeHtml));

이 sanitize 함수는 원본과 동일한 설정을 사용합니다.

보안 이슈 수정#

오래된 코드를 리팩토링할 때, 여전히 관련이 있을 수 있는 보안 이슈를 잡기 위해 작성된 스펙을 실수로 제거하지 않는 것이 중요합니다.

스펙에 #security를 describe 또는 it 블록에 표시하여, 코드를 읽는 엔지니어에게 이러한 스펙을 제거하면 나중에 심각한 결과를 초래할 수 있으며, 보안 이슈의 재도입을 감지할 수 있는 코드를 제거하는 것임을 알려야 합니다.