You have an AWS S3 bucket with the following CORS configuration:
{
"CORSRules": [
{
"AllowedOrigins": ["https://example.com"],
"AllowedMethods": ["GET", "POST"],
"AllowedHeaders": ["*"],
"MaxAgeSeconds": 3000
}
]
}What will happen if a web page hosted on https://anotherdomain.com tries to make a GET request to this bucket?
Check which origins are allowed in the CORS configuration.
The CORS configuration only allows requests from https://example.com. Requests from https://anotherdomain.com are blocked by the browser.
You want to configure an AWS S3 bucket to allow cross-origin requests from https://myapp.com for GET, PUT, and DELETE methods. Which CORS configuration below is correct?
Only include the methods you want to allow.
Option C correctly lists only GET, PUT, and DELETE methods for the specified origin.
An AWS S3 bucket has this CORS configuration:
{
"CORSRules": [
{
"AllowedOrigins": ["*"],
"AllowedMethods": ["GET", "PUT", "POST", "DELETE"],
"AllowedHeaders": ["*"],
"ExposeHeaders": ["ETag"],
"MaxAgeSeconds": 3000
}
]
}What is the main security risk of this configuration?
Think about what allowing all origins and methods means.
Allowing all origins and all methods means any website can read and write data, which is a security risk.
You have a web app hosted in two regions: https://us.example.com and https://eu.example.com. Both need to access the same AWS S3 bucket. How should you configure CORS to allow both origins?
You can list multiple origins in the AllowedOrigins array of a single CORS rule.
Option A correctly lists both origins in the AllowedOrigins array of a single CORS rule, which is supported in AWS S3.
You want to optimize your AWS S3 bucket's CORS configuration to reduce preflight requests and improve security. Which configuration change best achieves this?
Think about reducing preflight frequency and limiting access.
Specifying trusted origins and needed methods limits exposure. Increasing MaxAgeSeconds reduces preflight requests, improving performance.