A browser reports a CORS error, so the first instinct is often to change the origin. A site needs HSTS, CSP, or X-Content-Type-Options, so the next change goes into Nginx, an application framework, or an object-storage configuration. Those fixes can work, but they become difficult to maintain when several origins and cache behaviors need the same response rules.
A CloudFront response headers policy provides a centralized alternative. It lets CloudFront add or remove HTTP response headers at the edge before a response is delivered to the viewer. One reusable policy can manage CORS, browser security headers, custom headers, header removal, and Server-Timing settings without requiring application code changes.
The important limitation is in the name: this policy changes viewer responses. It does not define the cache key, decide which request values reach the origin, or independently control how long CloudFront stores an object. Understanding that boundary prevents many common CORS and caching mistakes.
What Is a CloudFront Response Headers Policy?
A response headers policy is a reusable CloudFront configuration attached to a cache behavior. When a request matches that behavior, CloudFront applies the policy before sending the response to the browser or another viewer.
A policy can perform several types of response processing:
Add and configure CORS headers such as Access-Control-Allow-Origin, Access-Control-Allow-Methods, and Access-Control-Allow-Headers.
Add browser security headers such as Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options, X-Frame-Options, and Referrer-Policy.
Add fixed custom response headers.
Remove selected headers received from the origin.
Add Server-Timing information for a configurable percentage of responses.
CloudFront applies the policy to responses served from its cache as well as responses fetched from the origin. This makes response headers policies useful when cached objects must receive a consistent set of viewer-facing headers.
Response Headers Policy vs Cache Policy vs Origin Request Policy
All three policies can appear on the same cache behavior, but they work at different points in the request and response flow.
Cache policy
A cache policy controls the cache key and the minimum, default, and maximum TTL values. Headers, cookies, and query strings included in the cache key can create separate cached variants.
Origin request policy
An origin request policy forwards additional viewer headers, cookies, and query strings to the origin when CloudFront makes an origin request. These additional values do not have to become part of the cache key.
Response headers policy
A response headers policy works in the opposite direction. It controls which headers CloudFront adds, removes, or overrides before the response reaches the viewer.
A simplified request flow looks like this:
The cache policy determines how CloudFront looks up the object.
On a cache miss, the origin request policy determines which additional request values go to the origin.
After CloudFront has a response, the response headers policy prepares the headers delivered to the viewer.
A particularly important detail involves Cache-Control. Adding Cache-Control through a response headers policy changes the header in the viewer response and can influence browser caching. It does not change the way CloudFront caches the object. CloudFront caching still depends on the cache policy, origin cache directives, and the applicable TTL rules.
How to Configure CORS in a Response Headers Policy
Cross-Origin Resource Sharing controls whether browser code loaded from one origin can read a resource from another origin. It frequently affects fonts, images, JavaScript modules, object-storage downloads, and API requests.
Before creating a CORS policy, answer four questions:
Which origins should be allowed?
Which HTTP methods are required?
Which request headers must the browser be allowed to send?
Will the request include credentials such as cookies or authorization information?
Allowed origins
Public assets may be able to use a wildcard origin. Authenticated APIs, account pages, and administrative endpoints should normally use an explicit list of trusted origins.
Credentialed browser requests cannot rely on Access-Control-Allow-Origin: *. The response must identify an allowed origin, and the other CORS settings must also be compatible with credentialed requests.
Keep development and production origins separate. A localhost origin or temporary staging domain that was useful during testing should not remain in a production policy without a reason.
Allowed methods
Static content normally requires GET, HEAD, and sometimes OPTIONS. An API may additionally require POST, PUT, PATCH, or DELETE. Allow the methods that the application actually uses instead of enabling every method by default.
Allowed headers
List the request headers required by the application, such as Content-Type or Authorization. In CloudFront CORS settings, Authorization cannot be covered by the general wildcard and must be listed explicitly.
This detail often explains why a basic request works while an authenticated request fails during preflight.
Preflight requests
For many non-simple cross-origin requests, the browser sends an OPTIONS request before the actual request. A correct response headers policy is only one part of the solution. You should also verify that:
The cache behavior allows OPTIONS.
The origin or edge logic can produce an appropriate preflight response.
Required request values are forwarded when the origin needs them.
The cache key separates preflight responses when different request origins, methods, or headers require different results.
If different Origin values should receive different Access-Control-Allow-Origin results but all requests share one cached response, CloudFront can return a CORS result created for another origin. Review whether Origin, Access-Control-Request-Method, and Access-Control-Request-Headers need to be part of the caching and forwarding design.
Origin override
The Origin override setting determines what happens when the origin already returns a CORS header also configured in the policy.
When override is enabled, CloudFront uses the value from the response headers policy and ignores the corresponding origin value. This is useful when multiple origins need one consistent edge-managed rule.
When override is disabled, an existing CORS header from the origin is preserved. This is more appropriate when the application calculates a dynamic result based on the tenant, user, path, or request origin.
Avoid maintaining two conflicting sources of truth. Duplicate or inconsistent Access-Control-Allow-Origin headers can still cause the browser to reject the response.
Choosing Security Headers
A response headers policy can establish a common browser security baseline, but enabling every available option is not automatically safer. Incorrect values can block legitimate assets or break application features.
Strict-Transport-Security
HSTS tells compatible browsers to use HTTPS for the site during the configured period. Before enabling a long max-age, verify that the domain and any subdomains covered by includeSubDomains reliably support HTTPS.
The preload directive has additional operational consequences because it relates to browser preload lists. Do not enable it casually when old subdomains, certificate coverage, or redirect behavior remain uncertain.
Content-Security-Policy
CSP restricts where scripts, styles, images, fonts, frames, and other resources may be loaded from. It is powerful and easy to make too restrictive.
Inventory analytics, payment services, customer-support widgets, font hosts, image domains, and other third-party dependencies before enforcing a policy. A complex application can first use Content-Security-Policy-Report-Only, added as a custom header, to collect violations without immediately blocking resources. The final enforcement policy can then be tightened from observed data.
CloudFront limits the Content-Security-Policy value in the security headers section, so very large policies may also require simplification or a different implementation approach.
X-Content-Type-Options
The usual value is nosniff. It tells browsers not to reinterpret a resource as another content type. Before enabling it, make sure JavaScript, CSS, fonts, and downloadable files have correct Content-Type headers at the origin.
X-Frame-Options
DENY prevents the page from being framed, while SAMEORIGIN permits same-origin framing. Test carefully if the application uses embedded consoles, third-party authentication, or iframe integrations.
For more precise framing rules, evaluate the CSP frame-ancestors directive as part of the site's broader security policy.
Referrer-Policy
Referrer-Policy controls how much information about the current page is included when the browser navigates or requests another resource. strict-origin-when-cross-origin is a common balanced choice, but applications that depend on complete Referer paths should be tested before changing the policy.
When to Use Custom Response Headers
Custom response headers are appropriate for fixed, public information that should be added consistently. Examples include:
A public edge-configuration version identifier.
A non-sensitive environment label used by a frontend or troubleshooting tool.
A fixed business or compliance response field.
A standard header not directly available in the security headers section.
Do not place secrets, internal addresses, private user identifiers, or values that can bypass security checks in viewer response headers. Anyone can inspect them with browser developer tools or an HTTP client.
Custom response headers are also not a substitute for dynamic application logic. If a value must change by user, cookie, path, authentication result, or origin response, evaluate CloudFront Functions, Lambda@Edge, or origin-side code.
Removing Origin Response Headers
A response headers policy can remove selected fields before the response reaches the viewer. For example, an origin may return a framework or software-identification header that the client does not need.
CloudFront performs configured removal before it adds headers from other sections of the same policy. If the same header is removed and then added elsewhere in the policy, the added value appears in the final viewer response.
Not every HTTP header can be removed. CloudFront maintains a list of restricted headers, and the console or API rejects unsupported removal entries.
Before removing a header, confirm that it is not used by browsers, API clients, download tools, monitoring systems, or caching logic. A field that appears unnecessary may still participate in content negotiation, downloads, CORS, or browser caching.
Managed Policies or a Custom Policy?
AWS provides managed response headers policies for common configurations, including basic CORS, CORS with preflight, common security headers, and combinations of CORS and security headers.
Managed policies are useful when the predefined values match the application. AWS maintains them, but you cannot edit their settings.
Create a custom policy when you need to:
Restrict CORS to specific origins.
Select a custom HSTS duration.
Define an application-specific CSP.
Add or remove custom headers.
Choose different override behavior.
Configure Server-Timing sampling.
Review the exact contents of a managed policy before attaching it. Its name alone does not prove that its values match the site's production requirements.
Three Practical Configuration Patterns
Public static assets
For public images, CSS, JavaScript, fonts, or downloads:
Allow only the CORS origins required by the product, or use a wildcard only when the assets are intentionally public and no credentials are involved.
Limit methods to GET, HEAD, and OPTIONS where applicable.
Add nosniff and an appropriate Referrer-Policy.
Configure CloudFront TTLs separately in the cache policy.
Credentialed API
For a cross-origin API that uses cookies or authorization:
Use explicit allowed origins rather than a wildcard.
List the required methods and request headers.
Include Authorization explicitly when it is required.
Verify that OPTIONS requests receive a correct response.
Design the cache key and origin forwarding around Origin and other values that affect the response.
Do not place private user responses in a shared public cache.
Site-wide security baseline
For a site with multiple origins or cache behaviors:
Test CSP, HSTS, framing, fonts, and third-party integrations on a staging distribution or path.
Decide whether CloudFront or the origin owns each header.
Test HTML, static assets, API routes, and error responses separately.
Monitor browser console errors and CSP reports after deployment.
Different content types have different requirements. It is often safer to attach separate response headers policies to HTML, public assets, and authenticated APIs instead of forcing every cache behavior to share one policy.
How to Create and Attach the Policy
In the AWS Management Console:
Open CloudFront and go to Policies > Response headers.
Select an AWS managed policy or create a custom response headers policy.
Configure the required CORS, security, custom, removal, and Server-Timing settings.
Open the target distribution and edit the appropriate cache behavior.
Select the policy under Response headers policy and save the behavior.
Wait for the distribution configuration to finish deploying, then test through the real viewer domain.
Before editing a reusable custom policy, identify every cache behavior that uses it. One policy can be attached to multiple cache behaviors and distributions in the same account, so a change can affect more sites than expected. If only one application should change, create a separate policy instead.
Testing the Final Response
A deployed status in the console does not confirm that the browser receives the intended result. Test normal requests, cached responses, and OPTIONS preflight requests.
Check a normal response:
curl -I https://www.example.com/app.js
Send a request with a specific Origin:
curl -I https://www.example.com/app.js \ -H "Origin: https://app.example.com"
Test a preflight request:
curl -i -X OPTIONS https://api.example.com/v1/data \ -H "Origin: https://app.example.com" \ -H "Access-Control-Request-Method: POST" \ -H "Access-Control-Request-Headers: Authorization,Content-Type"
Review Access-Control-Allow-Origin, Access-Control-Allow-Methods, Access-Control-Allow-Headers, Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options, and Referrer-Policy in the result.
Compare cache hits and misses as well. If an old header still appears, confirm that the policy is attached to the correct cache behavior, the request path matches that behavior, and the browser or an intermediate proxy is not reusing an older response.
Common Configuration Mistakes
Treating a response headers policy as a cache policy
A response headers policy can add Cache-Control to the viewer response, but it does not independently define CloudFront's cache key or edge TTL. Inspect the cache policy and origin cache directives when troubleshooting edge caching.
Using a wildcard with credentials
A browser credentialed request requires an explicit allowed origin. Access-Control-Allow-Origin: * is not accepted for a response exposed to a credentialed request.
Returning conflicting headers from the origin and CloudFront
Without a clear override design, the final response may contain duplicate or inconsistent values. Assign ownership of each header to the origin or the edge policy.
Reusing one policy for every path
HTML pages, public static assets, and private APIs have different risks. Separate policies by cache behavior when their requirements differ.
Enforcing a strict CSP immediately
A strict policy deployed without an inventory of third-party resources can block scripts, fonts, payment components, analytics, or support tools. Observe violations first when the application is complex.
Conclusion
CloudFront response headers policies provide a reusable way to manage CORS, browser security headers, custom response metadata, header removal, and Server-Timing at the edge. They work for cached and origin-fetched responses, which makes them useful for enforcing consistent viewer-facing behavior across several origins.
Their scope remains specific: a response headers policy does not define the cache key, replace an origin request policy, or independently change CloudFront's edge TTL. A reliable setup separates public assets, HTML pages, and credentialed APIs, then tests preflight requests, cache hits, and real browser behavior before a production rollout.
CloudFlew provides CDN services based on AWS CloudFront. If you are planning a CDN deployment, HTTPS configuration, or global delivery optimization, visit the CloudFlew CDN product page for current service information.
References
AWS CloudFront Developer Guide: Add or remove HTTP headers in CloudFront responses with a policy
AWS CloudFront Developer Guide: Understand response headers policies
AWS CloudFront Developer Guide: Use managed response headers policies
MDN Web Docs: Cross-Origin Resource Sharing (CORS)
