보안

GitLab 프론트엔드 개발에서 보안을 유지하기 위한 지침으로, 외부 리소스 제한, 인라인 스크립트 방지, HTML 새니타이징 방법을 설명합니다.

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