Description
S3 CORS governs how browser applications from another origin can use bucket resources. Unnecessarily broad origins or methods can let unintended web pages use requests that are already authorized. CORS does not itself grant S3 read or write permissions or bypass policies and authentication.
Potential impact
- More origins may be able to read authorized responses through a browser.
- Where write permissions or signed requests are available, unnecessary upload or deletion paths may become usable from the browser.
Remediation
- Allow the application’s actual HTTPS origins and required methods and headers. Assess deliberate broad access to public content separately.
- Choose each method, including
PUT,POSTandDELETE, according to functionality; the method name alone does not determine safety. - Restrict S3 permissions separately and test that required browser requests work.
Examples
This example assumes that the application needs only GET and POST. Specify the origin’s scheme and host without a path, and adapt the origin and required request headers to the application.
Before
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
All five methods are allowed, including PUT, DELETE and HEAD, which this application does not need.
After
yaml
- name: S3 CORS 규칙 설정
community.aws.aws_s3_cors:
name: mys3bucket
state: present
rules:
- allowed_origins:
- https://www.example.com
allowed_methods:
- GET
- POST
Only the required GET and POST methods remain. POST can also perform writes such as uploads, so apply the relevant S3 permissions and request validation separately.