마이크로 프론트엔드 보안 고려사항

Module Federation 환경에서 런타임 코드 로딩이 만드는 다섯 가지 보안 위협과 실무 대응 전략을 정리한다.

학습 목표

1. Module Federation이 전통적 번들링과 다른 보안 표면(attack surface)을 이해한다.
2. 외부 코드 신뢰성, 의존성 관리, CORS, 버전 호환성, 데이터 노출 다섯 가지 영역의 위험을 식별한다.
3. 각 위험에 대한 실무 완화 전략을 설명할 수 있다.

---

1. 보안 위협 전체 지도

마이크로 프론트엔드는 런타임에 외부 원격 모듈을 불러온다. 이 구조가 기존 모놀리식 번들에는 없던 보안 위협을 만든다.

위 다이어그램처럼 호스트가 런타임에 원격 모듈을 로드하는 순간, 다섯 가지 보안 위협이 동시에 존재하게 된다.

---

2. 외부 코드 신뢰성 문제

문제 상황

Module Federation은 remoteEntry.js를 런타임에 가져온다. 이 파일의 내용은 빌드 시점이 아닌 요청 시점에 결정된다. 외부 팀이 제공하는 로그인 모듈에 잘못 구성된 라이브러리, 악의적인 코드 조각, 또는 취약한 종속성이 포함되어 있다면 호스트 애플리케이션 전체의 보안이 위협받는다.

공격 시나리오

• 원격 모듈 서버가 탈취되어 변조된 remoteEntry.js가 서빙되는 경우
• 외부 팀의 코드에 XSS 취약점이 있는 라이브러리가 포함된 경우
• 서드파티 CDN을 경유하면서 중간자 공격(MITM)이 발생하는 경우

대응 전략

전략	설명
코드 리뷰 의무화	원격 모듈의 코드 변경을 호스트 팀이 리뷰하는 프로세스 수립
자동화된 취약점 스캐닝	CI 파이프라인에서 npm audit, Snyk, Dependabot 등 자동 실행
SRI(Subresource Integrity)	스크립트 태그에 integrity 해시를 부여하여 변조 감지
스테이징 검증	프로덕션 배포 전 스테이징 환경에서 원격 모듈 동작 사전 검증
CSP(Content Security Policy)	허용된 스크립트 출처만 실행 가능하도록 정책 설정

---

3. 의존성 관리와 취약점

문제 상황

마이크로 프론트엔드 환경에서는 여러 팀이 각자의 package.json을 관리한다. 공유하는 공통 UI 라이브러리가 오래된 버전의 lodash에 의존하고 있다면, 그 취약점은 모든 마이크로 앱에 전파된다.

의존성 보안 프로세스

핵심 원칙

• 자동화된 취약점 스캐닝: CI 파이프라인에 npm audit --audit-level=high를 필수 단계로 포함한다.
• 정기적인 업데이트: 주간 또는 격주로 의존성 업데이트를 검토한다.
• 최소한의 종속성 원칙: 꼭 필요한 패키지만 설치하고, 불필요한 의존성은 제거한다.
• 공유 의존성 버전 관리: Module Federation의 shared 설정에서 singleton: true와 requiredVersion을 명시하여 의존성 버전을 통제한다.

// webpack.config.js 예시
new ModuleFederationPlugin({
  shared: {
    react: {
      singleton: true,
      requiredVersion: '^18.2.0',
      eager: false,
    },
    'react-dom': {
      singleton: true,
      requiredVersion: '^18.2.0',
    },
  },
});

---

4. CORS 설정 주의점

문제 상황

Module Federation은 다른 도메인에서 JavaScript 번들을 가져온다. 이때 CORS(Cross-Origin Resource Sharing) 설정이 필수적이다. 너무 개방적인 CORS 정책은 악의적인 출처에서도 리소스에 접근할 수 있게 만든다.

개발 환경 vs 프로덕션 환경

항목	개발 환경	프로덕션 환경
Access-Control-Allow-Origin	* (편의상 전체 허용)	https://app.example.com (명시적 출처)
Access-Control-Allow-Methods	전체 허용	GET만 허용 (정적 리소스)
Access-Control-Allow-Credentials	미설정	필요 시에만 true
Access-Control-Max-Age	짧게	충분히 길게 (캐시 효율)

CORS 설정 원칙

1. 명시적 출처 지정: Access-Control-Allow-Origin에 와일드카드(*)를 사용하지 않고 구체적인 도메인을 지정한다.
2. 필요한 메소드만 허용: 원격 모듈 서빙은 대부분 GET 요청이므로 다른 메소드는 차단한다.
3. 자격증명 처리: 쿠키나 인증 토큰이 필요한 경우에만 Access-Control-Allow-Credentials를 설정한다.
4. 프리플라이트 캐싱: Access-Control-Max-Age를 적절히 설정하여 불필요한 OPTIONS 요청을 줄인다.

---

5. 버전 호환성과 보안 업데이트

문제 상황

호스트가 React 18을 사용하고 원격 모듈이 React 17을 사용하면 런타임 충돌이 발생할 수 있다. 이는 단순한 버그를 넘어 보안 패치가 적용되지 않은 구버전 라이브러리가 프로덕션에 로드되는 상황을 만든다.

대응 전략

전략	설명	적합한 상황
단일 버전 정책	모든 마이크로 앱이 동일한 주요 라이브러리 버전 사용	팀 수가 적고 동기화가 쉬운 경우
호환 범위 정책	semver 범위 내에서 자유롭게 선택	팀 자율성이 중요한 경우
공유 의존성 분리	핵심 라이브러리를 별도 패키지로 분리하여 런타임에 공유	대규모 조직

보안 업데이트 프로세스

보안 취약점이 발견되면 모든 마이크로 앱이 동시에 업데이트되어야 한다. 한 팀이 업데이트를 미루면 전체 시스템이 취약해진다. 따라서 핵심 보안 패치에 대해서는 일정 기한 내 업데이트를 강제하는 정책이 필요하다.

---

6. 데이터 노출 방지 (민감 데이터 격리)

문제 상황

마이크로 프론트엔드 간 데이터 공유 과정에서 민감한 사용자 정보가 노출될 수 있다. API 응답 데이터가 암호화되지 않은 채 전달되거나, 원격 모듈 자체에 보안 취약점이 있으면 중간자 공격으로 데이터가 유출될 수 있다.

격리 원칙

1. 최소 데이터 전달: 마이크로 앱 간에는 인증 토큰이나 세션 ID만 전달하고, 실제 데이터는 각 앱이 API를 직접 호출하여 획득한다.
2. 전역 상태 최소화: window 객체나 전역 스토어에 민감 데이터를 저장하지 않는다.
3. HTTPS 강제: 모든 원격 모듈 로딩과 API 통신은 HTTPS를 사용한다.
4. 접근 권한 관리: 각 마이크로 앱이 접근할 수 있는 API 엔드포인트를 엄격히 제한한다.
5. 중복 요청 감수: 각 앱이 독립적으로 데이터를 요청하면 중복이 발생하지만, 보안과 독립 배포라는 이점을 위해 감수한다.

---

핵심 정리

보안 영역	핵심 위험	최우선 대응
코드 신뢰성	변조된 원격 모듈 로딩	코드 리뷰 + SRI + CSP
의존성 관리	취약한 공유 패키지 전파	npm audit 자동화 + 정기 업데이트
CORS 설정	과도한 허용으로 인한 리소스 탈취	명시적 출처 + 최소 메소드 허용
버전 호환성	구버전 보안 패치 누락	단일 버전 정책 또는 업데이트 기한 강제
데이터 노출	마이크로 앱 간 민감 정보 유출	최소 데이터 전달 + HTTPS 강제

Module Federation의 런타임 로딩 특성은 기존 빌드타임 번들링에는 없던 보안 표면을 만든다. "개발 편의를 위해 전부 열어두고 나중에 조이자"는 접근은 위험하다. 처음부터 보안 정책을 수립하고 CI 파이프라인에 자동화된 검증을 내장하는 것이 핵심이다.

---

다음 단계

보안 정책이 마련되었다면, 이 정책을 실행하는 주체인 팀의 운영 구조를 설계해야 한다. 다음 장에서는 분산 팀 구조에서의 자율성과 통제의 균형, 기술 표준화 범위 설정, 지식 공유 제도에 대해 알아본다.

다음 문서: 02-팀-운영과-기술-다양성.md