S3 CORS 허용 범위 점검

S3 CORS는 웹 애플리케이션에 필요한 출처와 메서드만 허용하도록 구성해야 합니다.

설명

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 권한과 요청 검증을 별도로 적용하세요.

참조