설명
S3 CORS는 다른 출처에서 실행되는 브라우저 애플리케이션이 버킷 리소스를 사용하는 방식을 정합니다. 불필요하게 넓은 출처나 메서드를 허용하면 의도하지 않은 웹 페이지에서도 이미 허가된 요청을 이용할 수 있습니다. CORS 자체가 S3 읽기·쓰기 권한을 부여하거나 버킷 정책과 인증을 우회하지는 않습니다.
잠재적 영향
- 의도하지 않은 출처에서 권한이 있는 응답을 브라우저로 읽을 수 있는 범위가 넓어질 수 있습니다.
- 쓰기 권한이나 서명된 요청을 사용할 수 있는 경우, 불필요한 업로드·삭제 경로가 브라우저에 허용될 수 있습니다.
해결 방법
- 실제 애플리케이션의 HTTPS 출처와 필요한 메서드·헤더만 허용하세요. 공개 콘텐츠의 의도적인 범용 접근은 별도로 판단하세요.
PUT,POST,DELETE를 포함한 각 메서드를 기능 요구사항에 맞춰 선택하세요. 메서드 이름만으로 안전성을 판단하지 마세요.- CORS와 별개로 S3 권한을 제한하고 필요한 브라우저 요청의 성공 여부를 시험하세요.
예시
이 예제는 애플리케이션에 GET과 POST만 필요하다고 가정합니다. 출처는 경로 없이 스킴과 호스트를 지정하며, 실제 사용하는 출처와 필요한 요청 헤더에 맞추세요.
변경 전
yaml
- name: S3 CORS 규칙 설정
community.aws.aws_s3_cors:
name: mys3bucket
state: present
rules:
- allowed_origins:
- https://www.example.com
allowed_methods:
- GET
- POST
- PUT
- DELETE
- HEAD
다섯 메서드를 모두 허용합니다. 이 애플리케이션에 필요하지 않은 PUT, DELETE와 HEAD도 포함되어 있습니다.
변경 후
yaml
- name: S3 CORS 규칙 설정
community.aws.aws_s3_cors:
name: mys3bucket
state: present
rules:
- allowed_origins:
- https://www.example.com
allowed_methods:
- GET
- POST
필요한 GET과 POST만 남겼습니다. POST에도 업로드 등 쓰기 용도가 있으므로 관련 S3 권한과 요청 검증을 별도로 적용하세요.