[AWS] CloudFront HTTP 보안 헤더 적용

현재 CI/CD 구성을 통해, git push 후에 ZAP을 통해 보안취약점 검사를 자동으로 시행하게끔 설정되어있다.

이를 통해 현재 우리 시스템의 보안 취약점으로, 다음과 같은 HTTP 보안헤더들이 누락되어있음을 확인할 수 있었다.

아래 7개의 보안 취약점중 6개는 응답헤더 설정으로, 1개는 CloudFront Functions 설정을 통해 해결할 수 있다.

Content Security Policy (CSP) 헤더 미설정 (XSS, 코드 인젝션 방어용) → 응답헤더 설정
X-Frame-Options 또는 CSP frame-ancestors 미설정 (클릭재킹 방어) → 응답헤더 설정
X-Content-Type-Options 헤더 미설정 (MIME 스니핑 방지) → 응답헤더 설정
Strict-Transport-Security (HSTS) 미설정 (HTTPS 강제) → 응답헤더 설정
Cross-Origin Resource Policy 등 Spectre 취약점 관련 헤더 미설정 → 응답헤더 Custom 설정
Permissions Policy 헤더 미설정 (브라우저 기능 제한) → 응답헤더 Custom 설정
Server 헤더에 서버 버전 노출 → 응답헤더 Custom 설정/헤더 제거 설정

1. CloudFront Response 보안 헤더 설정

CloudFront의 응답 헤더 정책(Response Headers Policy) 기능을 사용하여 하나씩 적용해보도록 하겠다.

CloudFront의 응답헤더 정책은, AWS CloudFront가 최종 사용자에게 응답할 때,

HTTP 헤더를 추가하거나 제거하도록 구성하는 기능이다.

이를 통해 보안 헤더를 추가하여 웹 애플리케이션의 개인 정보 보호 및 보안을 개선하고

클라이언트 측의 취약점으로부터 보호할 수 있다.

CloudFront > 정책 > 응답 헤더 > 응답 헤더 정책 생성

나는 "SecurityHeadersPolilcy-All" 이라는 이름으로 정책을 생성했다.

2. 보안헤더 설정

2.1 Content-Security-Policy (CSP) 누락

개념과 발생 가능 위험

CSP는 브라우저가 로드할 수 있는 리소스(스크립트, 스타일, 이미지, 프레임 등)의 출처를 제한하는 보안 정책이다.

미설정시, 다음과 같은 위험이 발생할 수 있다.

XSS(크로스 사이트 스크립팅): 공격자가 악성 JavaScript 삽입 가능.
데이터 탈취·세션 하이재킹 가능.
광고 삽입, 피싱 페이지 변조 같은 UI 공격 가능.

적용 방법

CSP를 적용하기 전에는, 먼저 페이지가 사용하는 외부 리소스를 확인해야한다.

(Chrome 기준)

1. 브라우저에서 사이트 열기

예: www.example.com

2. 개발자 도구 열기

F12 또는
오른쪽 클릭 → 검사

3. Network 탭 선택

페이지 새로고침(F5) 해서 모든 요청을 로드
"All" 필터로 모든 요청을 보고, "Domain" 또는 "Name" 옆에 표시되는 호스트를 확인

4. 외부 도메인 필터링

www.example.com이 아닌 다른 도메인 목록을 찾는다.
예: cdnjs.cloudflare.com, fonts.googleapis.com, google-analytics.com 등

정리
- JS: .js 확장자
- CSS: .css 확장자
- 폰트: .woff, .woff2, .ttf
- 이미지: .jpg, .png, .svg, .gif
- API: .json 응답이나 /api/ 경로

default-src 'self';
script-src 'self' https://cdnjs.cloudflare.com;
style-src 'self' https://fonts.googleapis.com;
img-src 'self' data:;
font-src 'self' https://fonts.gstatic.com;
object-src 'none';
base-uri 'self';
frame-ancestors 'none';
form-action 'self';
connect-src 'self';
frame-src 'none';
media-src 'self';
manifest-src 'self';

이런식으로 적용하면 된다.

오리진 재정의를 선택하면 오리진이 어떤 응답을 보내든 CloudFront가 강제로 수정/추가해서 보안 헤더를 붙인다는 뜻이므로,

보안 헤더 설정에서는 오리진 재정의를 체크하는게 보통 안전하다고 한다.

2.2. X-Frame-Options / frame-ancestors 미설정 (클릭재킹 방어)

개념과 발생 가능 위험

X-Frame-Options는 페이지가 <iframe>에 로드되는 것을 제어한다.

"DENY" → 모든 프레임 차단
"SAMEORIGIN" → 같은 도메인만 허용
CSP의 frame-ancestors로도 설정 가능하다.

미설정시, 다음과 같은 위험이 발생할 수 있다.

Clickjacking: 공격자가 사이트를 iframe에 숨기고, 사용자 클릭을 유도해 원치 않는 동작 실행.
예: 은행 계좌 송금 버튼을 투명하게 덮어씌우는 공격.

적용 방법

X-Frame-Options: DENY

2.3. X-Content-Type-Options

개념

브라우저가 MIME 타입을 강제 인식하도록 지정.
예: X-Content-Type-Options: nosniff

미설정 시 위험

MIME 스니핑으로 파일 형식을 속여 스크립트 실행 유도.
이미지나 PDF로 위장한 악성 코드 실행 가능.

적용 방법

2.4. Strict-Transport-Security (HSTS)

개념

브라우저가 해당 사이트에 반드시 HTTPS로만 접속하도록 강제.
예: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

미설정 시 위험

중간자 공격(MITM) 가능: 첫 HTTP 요청에서 HTTPS로 리다이렉트하는 사이 공격 가능.
HTTPS 설정해도 HTTP 다운그레이드 공격에 노출될 수 있음.

적용 방법

1년(31536000초) 동안 HTTPS 강제
includeSubDomains → 모든 서브도메인 포함
preload → Chrome HSTS preload list에 등록 가능

3. 사용자 지정 헤더 설정

3.1 Cross-Origin Resource Policy (CORP), Cross-Origin-Opener-Policy (COOP), Cross-Origin-Embedder-Policy (COEP)

개념

다른 Origin(출처)에서 리소스 공유를 제어하는 보안 헤더.
Spectre 같은 CPU 사이드채널 취약점 완화.
예: Cross-Origin-Resource-Policy: same-origin

미설정 시 위험

악성 페이지가 브라우저 메모리에서 민감한 데이터 추출(Spectre 기반 공격).
비의도적인 리소스 공유로 개인정보 노출.

적용 방법

Cross-Origin-Resource-Policy: same-origin
Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp

위의 값을 아래와 같은 형태로 넣어주면 된다.

3.2. Permissions-Policy

개념

브라우저 기능 사용 권한을 페이지별로 제한.
예: Permissions-Policy: camera=(), microphone=(), geolocation=()

미설정 시 위험

악성 코드나 제3자 스크립트가 카메라, 마이크, 위치 정보 등 민감 기능 무단 사용.
사용자가 모르게 WebRTC 등을 통한 추적 가능.

적용 방법

현재 페이지의 필요에 맞게 설정하면 된다.

이름 → Permissions-Policy
값 → camera=(), microphone=(), geolocation=()
도메인 범위 지정
- * → 모든 도메인 허용
- self → 자기 도메인만 허용
예시

## 카메라(차단),마이크(차단),위치(모든사이트에서 허용)
Permissions-Policy: camera=(), microphone=(), geolocation=*

## 위치를 현재 사이트에서만 허용
Permissions-Policy: camera=(), microphone=(), geolocation=(self)

사용자 지정 헤더에서 Custom으로 추가해준다.

3.3 Server 헤더 제거

개념

응답 헤더의 Server 값에서 서버 종류·버전 노출을 막음.
예: Server: AmazonS3 → 제거 또는 Server: Secure

미설정 시 위험

공격자가 서버 소프트웨어와 버전을 알아내 취약점 사전 조사 가능.
자동화된 공격 스캐너에 노출될 확률 증가.

적용 방법

방법 1: 사용자 지정 헤더에서, 값을 아무것도 입력 안하는 방법

장점: 모든 브라우저/툴에서 Server: 헤더는 존재하지만 값이 비어있음 → 버전 노출 방지

방법 2: 헤더를 아예 제거하는 방법

완전히 응답에서 빠지게 함 (헤더 자체가 안 보임)
장점: 깔끔하게 헤더 자체가 없어짐
단점: 일부 로깅/모니터링 도구에서 “Server 헤더 없음”을 경고할 수 있음 (기능상 문제는 없음)

4. 적용 및 검증

응답 정책을 만드는 것만으로는 적용이 되지 않는다.

다음 과정을 통해 정책을 적용시킬 수 있다.

4.1 배포 동작 적용

배포 > 동작 > 동작 생성/편집

기본 배포 동작을 수정해도 되고, 새로 생성해도 된다.

응답 헤더 정책 부분에서, 위에서 생성한 정책을 선택해준다.

4.2 캐시 무효화

배포 > 무효화 > 무효화 생성

나는 디폴트경로에 대해 정책을 적용했으므로,

/* 를 통해 전체 경로에 대해 캐시 무효화를 진행하면 된다.

4.3 검증

curl -I -H https://www.example.com/

다음 명령어를 통해, 점검중인 사이트의 실제 응답 HTTP 헤더를 확인해볼 수 있다.

ZAP Report에서도 취약점이 해결된 것을 확인할 수 있다.

'AWS' 카테고리의 다른 글

[AWS][트러블슈팅] 도커파일 USER 미지정 문제 해결 (3)	2025.08.12
[AWS][트러블슈팅] CodeDeploy 오류 해결 (ResourceInitializationError, Only target group in ECS deployment group) (1)	2025.08.06
[AWS][트러블슈팅] 프론트 -> 백엔드 API 요청 막힘 문제 해결 (2)	2025.08.06
[AWS] EC2 to ECS 마이그레이션 (Spring 프로젝트, https) (3)	2025.08.04
[AWS] SQS로 비동기로 요청 처리하기 (6)	2025.07.25

1. CloudFront Response 보안 헤더 설정

2. 보안헤더 설정

2.1 Content-Security-Policy (CSP) 누락

2.2. X-Frame-Options / frame-ancestors 미설정 (클릭재킹 방어)

2.3. X-Content-Type-Options

2.4. Strict-Transport-Security (HSTS)

3. 사용자 지정 헤더 설정

3.1 Cross-Origin Resource Policy (CORP), Cross-Origin-Opener-Policy (COOP), Cross-Origin-Embedder-Policy (COEP)

3.2. Permissions-Policy

3.3 Server 헤더 제거

4. 적용 및 검증

4.1 배포 동작 적용

4.2 캐시 무효화

4.3 검증

'AWS' 카테고리의 다른 글

티스토리툴바