5.1 CloudFront Security Headers & Origin Access Control

5.1 CloudFront Security Headers & Origin Access Control

Securing public-facing web applications begins at the network perimeter. Amazon CloudFront is a global Content Delivery Network (CDN) that terminates client transport connections across hundreds of Points of Presence (PoPs). In an enterprise security architecture, CloudFront acts as both a performance accelerator and a defensive shield. It isolates backend application origins, enforces strict transport encryption, filters geographic traffic, and injects critical browser-hardening headers.

Mastering CloudFront edge security for the AWS Certified Security – Specialty exam requires deep technical knowledge of Origin Access Control (OAC) versus legacy Origin Access Identity (OAI), bucket policy authorization patterns, response headers policies, viewer and origin protocol policies, and cryptographic private content distribution using Signed URLs and Signed Cookies.

---

Response Headers Policies: Edge-Native Browser Hardening

Modern web browsers implement robust security controls governed by HTTP response headers. Historically, injecting security headers into web responses required modifying origin application source code, configuring origin web server daemons (e.g., Apache or NGINX), or deploying compute-intensive Lambda@Edge or CloudFront Functions to modify responses on viewer-response events.

CloudFront Response Headers Policies eliminate edge compute overhead and latency by natively adding or overriding HTTP response headers directly at edge PoPs before responses are delivered to viewers.

Loading diagram...

Core Defensive Security Headers

When configuring a response headers policy (either using the AWS managed SecurityHeadersPolicy or a custom policy), security engineers enforce the following standard defensive headers:

Managed vs Custom Response Headers Policies

AWS provides preconfigured managed policies, including Managed-SecurityHeadersPolicy and Managed-CORS-and-SecurityHeadersPolicy. However, enterprise applications frequently require custom response headers policies to tailor CSP directives to internal content repositories or specify custom Access-Control-Allow-Origin values. Crucially, a response headers policy can be configured with Override = true or Override = false:

• If Override is set to true, CloudFront replaces any corresponding header returned by the origin.
• If Override is set to false, CloudFront injects the configured header only if the origin response does not already contain it.

Exam Tip: For the exam, recognize that CloudFront Response Headers Policies are the AWS recommended best practice for inserting security headers. They execute with zero compute cost and lower latency than Lambda@Edge or CloudFront Functions. Do not choose edge compute solutions for static header injection unless dynamic runtime calculation (such as inspecting user session tokens to construct unique per-user CSP nonces) is explicitly required.

---

Origin Access Control (OAC) vs Origin Access Identity (OAI)

When using Amazon S3 as a CloudFront origin, public read access must be disabled on the S3 bucket to prevent users from bypassing CloudFront caching, geographic restrictions, and AWS WAF inspection. Securing this communication requires an origin authorization mechanism.

Origin Access Identity (OAI) was the legacy mechanism introduced in earlier AWS architecture. Origin Access Control (OAC) is the modern, secure replacement introduced to overcome severe cryptographic and operational limitations of OAI.

Loading diagram...

Architectural Comparison: OAC vs OAI

Why OAI Fails with SSE-KMS

Understanding the mechanics of the SSE-KMS limitation is a cornerstone of the SCS-C03 exam. When an S3 object is encrypted with AWS Key Management Service (aws:kms), S3 must invoke kms:Decrypt using the identity of the caller. AWS lists SSE-KMS support as an OAC capability that OAI lacks: OAI requests are not SigV4-signed by the CloudFront service principal, so there is no principal a KMS key policy can authorize for the distribution. Requests through OAI for SSE-KMS objects therefore fail with Access Denied.

In contrast, OAC generates a full SigV4 signature using the CloudFront service principal (cloudfront.amazonaws.com). S3 evaluates this signature against its bucket policy and forwards the caller context to AWS KMS, which evaluates the KMS key policy granting decryption rights to CloudFront.

---

S3 Bucket Policy & KMS Key Policy Architecture for OAC

To lock down an S3 bucket so that objects are accessible exclusively through an authorized CloudFront distribution using OAC, two policies must be configured: the S3 Bucket Policy and, if SSE-KMS is enabled, the AWS KMS Key Policy.

S3 Bucket Policy Implementation

The S3 bucket policy must grant s3:GetObject permissions to the cloudfront.amazonaws.com service principal. To prevent the Confused Deputy Problem—where an attacker provisions their own CloudFront distribution in another AWS account pointing at your bucket—the policy must enforce an AWS:SourceArn condition matching the specific distribution ARN:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowCloudFrontServicePrincipalReadOnly",
      "Effect": "Allow",
      "Principal": {
        "Service": "cloudfront.amazonaws.com"
      },
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::production-secure-content-bucket/*",
      "Condition": {
        "StringEquals": {
          "AWS:SourceArn": "arn:aws:cloudfront::123456789012:distribution/EDFDVBD6EXAMPLE"
        }
      }
    }
  ]
}

Exam Trap: Pay close attention to the Resource ARN in the bucket policy. The action s3:GetObject applies to objects inside the bucket (arn:aws:s3:::bucket-name/*), not the bucket itself (arn:aws:s3:::bucket-name). Omitting the /* wildcard results in an Access Denied error when CloudFront fetches objects. If the distribution supports file uploads via PUT or POST, you must also include s3:PutObject in the Action array.

AWS KMS Key Policy for SSE-KMS Encryption

If the S3 bucket is encrypted using a customer-managed key (CMK), the KMS key policy must grant CloudFront permission to decrypt the data keys. Using the default AWS-managed key aws/s3 will not work because the AWS-managed key policy cannot be modified to grant permissions to the CloudFront service principal.

The customer-managed KMS key policy must contain the following statement:

{
  "Sid": "AllowCloudFrontServicePrincipalKMSDecryption",
  "Effect": "Allow",
  "Principal": {
    "Service": "cloudfront.amazonaws.com"
  },
  "Action": [
    "kms:Decrypt",
    "kms:GenerateDataKey*"
  ],
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "AWS:SourceArn": "arn:aws:cloudfront::123456789012:distribution/EDFDVBD6EXAMPLE"
    }
  }
}

---

Viewer & Origin Protocol Policies

CloudFront sits between viewers (clients) and origins. Transport security must be configured across both network segments.

Loading diagram...

Viewer Protocol Policy

The Viewer Protocol Policy governs how CloudFront responds to client connections over HTTP:

• redirect-to-https: If a viewer sends an unencrypted HTTP request, CloudFront automatically responds with an HTTP status code 301 Moved Permanently redirecting the client to the HTTPS equivalent URL on port 443. This provides the best user experience for human web visitors who type plain domain names into address bars.
• https-only: CloudFront terminates the connection or returns an HTTP status code 403 Forbidden if a request arrives over unencrypted HTTP. This is standard for REST APIs, mobile backends, and programmatic machine-to-machine integrations where clients must never transmit credentials or payloads over cleartext.
• allow-all: CloudFront accepts both HTTP and HTTPS requests without redirecting. This is an anti-pattern in security architectures and should never be used for protected workloads.

Origin Protocol Policy

The Origin Protocol Policy governs the connection between CloudFront edge PoPs and custom origins (such as an Application Load Balancer or EC2 instance):

• https-only: CloudFront initiates connections to the origin strictly over TLS port 443, regardless of the protocol used by the viewer. This ensures end-to-end encryption.
• match-viewer: CloudFront mirrors the viewer's protocol. If the viewer connected via HTTP, CloudFront calls the origin via HTTP. If the viewer connected via HTTPS, CloudFront calls the origin via HTTPS.
• Origin SSL Protocols: Security engineers configure the minimum SSL/TLS version supported between CloudFront and the origin (e.g., enforcing TLSv1.2 or TLSv1.3 and disabling legacy TLSv1.0 and TLSv1.1).
• Host Header and Certificate Validation: When CloudFront connects to a custom origin over HTTPS, it validates the origin server's TLS certificate. The domain name on the origin's certificate must match the Origin Domain Name configured in the CloudFront distribution settings.

---

Private Content Distribution: Signed URLs vs Signed Cookies

To restrict access to premium, subscription-based, or confidential content, CloudFront provides two cryptographic mechanisms: Signed URLs and Signed Cookies.

Architectural Comparison

Canned Policy vs Custom Policy

Both signed URLs and signed cookies can be constructed using either a Canned Policy or a Custom Policy:

Canned Policy Attributes:
  - Resource URL (exact match, no wildcards)
  - Expiration Date/Time (Epoch timestamp)

Custom Policy Attributes:
  - Resource URL (supports wildcards, e.g., https://example.com/premium/*)
  - Expiration Date/Time (Epoch timestamp)
  - Optional: Activation Date/Time (Epoch timestamp - link valid only starting in the future)
  - Optional: IP Address Restriction (CIDR block, e.g., 198.51.100.0/24)

Exam Tip: If an exam question requires granting temporary access to a single video file that expires in 15 minutes, choose a Signed URL with a Canned Policy. If the scenario requires granting access to an entire directory of files, restricting access to a corporate IP address range, or setting a future start time, you must use a Custom Policy (with Signed Cookies or Signed URLs).

Trusted Key Groups vs Legacy Trusted Signers

When verifying signatures on signed URLs or cookies, CloudFront must validate the signature against a public key:

• Legacy Trusted Signers: Required an AWS account root user to create CloudFront key pairs in the AWS account management console. Sharing keys required adding AWS account IDs as trusted signers. Security anti-pattern: Violates the principle of avoiding root user usage.
• Trusted Key Groups (Current Standard): Allows security engineers to create an asymmetric public-private key pair (RSA 2048-bit), upload the public key to CloudFront using the CreatePublicKey API, and add the public key to a Key Group (CreateKeyGroup). IAM users or roles with appropriate permissions can rotate keys programmatically without root account access.

---

CloudFront Geographic Restrictions

Organizations frequently face regulatory mandates (e.g., export compliance, OFAC sanctions) or digital rights licensing agreements that require restricting access by geographic origin.

CloudFront offers built-in Geographic Restrictions (Geo-blocking):

• Allowlist: Only viewers in specified countries (identified by two-letter ISO 3166-1 alpha-2 country codes) can access content. Viewers from any other country receive an HTTP 403 Forbidden response.
• Blocklist: Viewers in specified countries are denied access with an HTTP 403 Forbidden response, while viewers from all other countries are permitted.
• Edge Evaluation: Geographic restrictions are evaluated directly at the edge PoP using an internal GeoIP database before the request reaches the cache or origin.

CloudFront Geo-Restriction vs AWS WAF Geo-Match

---

Specialty Exam Pitfalls & Architectural Traps

1. Migrating from OAI to OAC without Updating Bucket Policies: When updating a CloudFront distribution from OAI to OAC, the S3 bucket policy must be updated to grant permissions to cloudfront.amazonaws.com with AWS:SourceArn. If you switch the distribution origin to OAC while retaining the old OAI principal (arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity EXXXXX), all origin requests will immediately fail with HTTP 403.
2. Confused Deputy in OAC Bucket Policies: A bucket policy that grants s3:GetObject to cloudfront.amazonaws.com without a Condition block containing AWS:SourceArn or AWS:SourceAccount allows any CloudFront distribution in any AWS account to read your bucket objects. Always enforce AWS:SourceArn targeting your specific distribution ARN.
3. Using AWS-Managed Keys (aws/s3) with CloudFront OAC: S3 server-side encryption with AWS-managed keys (SSE-KMS using alias/aws/s3) does not allow modifying the key policy. Because CloudFront OAC requires explicit kms:Decrypt permissions granted in the KMS key policy, you must use a customer-managed key (CMK) when encrypting S3 objects intended for OAC distribution.
4. Cookie Domain Scope for Signed Cookies: When issuing CloudFront signed cookies, the Domain attribute in the Set-Cookie header must match or be a parent domain of the CloudFront distribution domain (e.g., Domain=.example.com for cdn.example.com). If the domain attributes mismatch, the browser will not send the cookies on subsequent asset requests, resulting in HTTP 403 errors.