Restrict viewer access separately from origin access

A CloudFront distribution can cache and deliver files around the world, but the fact that a file is cached does not decide which viewers should see it. Use signed URLs or signed cookies when the application must limit access to a particular customer, subscription, download or group of media objects. CloudFront validates the signed policy and signature; the application is still responsible for authenticating the viewer and deciding whether to issue that signed access. A content-delivery network is not a replacement for the application’s entitlement logic.

AWS CloudFront is a powerful content delivery network (CDN) service designed to accelerate the distribution of static and dynamic content globally. One of the critical features of CloudFront is its ability to restrict access to content, ensuring that only authorized users can view or download sensitive files. This is made possible through the use of signed URLs and signed cookies , two security mechanisms that provide granular control over who can access specific files or groups of files. In this article, we will explore how these tools work, when to use them, and how they can be implemented to enhance the security of your CloudFront distribution.

Protect the origin independently. If the same object remains publicly readable through its Amazon S3 URL, a viewer may bypass CloudFront’s signed-access requirement. Prefer a private S3 origin with CloudFront origin access control and an appropriate bucket policy. The S3 bucket permission model still governs which AWS principals can access underlying data. Signed viewer tokens restrict the CloudFront route; origin protection prevents direct paths from defeating that restriction. Evaluate both paths in a security test.

Generate and validate signed URLs for individual objects

Signed URLs are a method of granting time-limited access to specific content in AWS CloudFront. A signed URL includes a URL with additional parameters that specify who can access the content, for how long, and under what conditions. The signature embedded in the URL ensures that only users with the correct permissions can retrieve the content. Signed URLs are typically used when you need to secure access to a single file or resource. A signed URL typically includes: Expiration Date: The time after which the URL will no longer work, ensuring that access is temporary. Policy Restrictions: These might include restrictions such as allowing access only from specific IP addresses or a specific user agent (browser or application). Resource Path: The specific file or content that is being accessed. For example, if you’re delivering a software download, a signed URL can be used to restrict access to that particular file for a specified time frame. This means that only authorized users with the signed URL can access the file, and once the URL expires, the link becomes invalid.

To generate a signed URL, you need to have a CloudFront distribution with a private key. The private key is used to create a signature for the URL, which is then appended to the URL along with the relevant parameters (e.g., expiration time and resource path). When a user requests the content, CloudFront verifies the signature against the private key and checks whether the conditions, such as the expiration time, are met. Here’s an example of how the signed URL might look: https://d1234.cloudfront.net/resource/file.zip?Expires=1623495600&Signature=abcd1234xyz&Key-Pair-Id=APKA123456789 Expires=1623495600 – The expiration time (in Unix epoch format) when the URL will become invalid. Signature=abcd1234xyz – The encrypted signature that ensures the URL is valid and untampered. Key-Pair-Id=APKA123456789 – The ID of the key pair used to sign the URL.

You should use signed URLs when: Securing Individual Files: If you have a single file that you want to provide temporary access to, such as an image, video, or software download, signed URLs are ideal. Temporary Access: If you need to restrict access to content for a certain period, such as providing temporary download links for a promotional offer or subscription-based content. Limiting Access to Specific Users: If you need to limit access to users from specific locations, IP addresses, or devices, signed URLs provide the flexibility to set these parameters. For example, if you’re offering a paid download for software, a signed URL ensures that only authorized users who have paid for access can download the file. You can control how long the link remains valid and limit its use to specific IP addresses or ranges.

A modern CloudFront design uses trusted key groups containing public keys to validate signatures, while the signing service protects the corresponding private keys. The signed policy can set an expiry and, with a custom policy, additional constraints such as a validity start time or source IP range. A signed URL is a bearer capability for its valid period, so do not assume it remains secret after being pasted into a public log, analytics service or support ticket. Issue the narrowest supported policy consistent with the viewer experience and rotate keys through a controlled process.

Use signed cookies when the viewer needs a collection of files

Signed cookies are similar to signed URLs but are designed for scenarios where you need to provide access to multiple files or resources at once. Unlike signed URLs, which grant access to a single file, signed cookies can be used to authorize access to a collection of files, such as an entire media library, a series of images, or a set of video tutorials. Signed cookies provide a more efficient way of managing access to multiple resources because you don’t need to generate a separate signed URL for each file. Instead, the signed cookie is sent to the user’s browser, and the browser automatically uses it to access the required files as needed. This makes signed cookies particularly useful in scenarios such as subscription-based services, where multiple files must be accessed by the same user. A typical use case for signed cookies is when you want to provide authorized users access to a collection of protected content (e.g., a set of training videos, media files, or documents) without needing to sign each file individually.

To implement signed cookies in CloudFront, you need to generate a set of cookies that contain the necessary authorization information. These cookies are then sent to the user’s browser, which uses them to authenticate requests for the protected resources. There are three main cookies that CloudFront generates for each request: CloudFront-Policy: A policy that defines the conditions for access, such as the expiration time, allowed IP addresses, and the resources that can be accessed. CloudFront-Signature: A digital signature that verifies the authenticity of the cookie. CloudFront-Key-Pair-Id: The key pair ID associated with the private key used to sign the cookie. When a user’s browser sends a request for protected content, CloudFront checks the signed cookies to verify whether the user is authorized to access the content. If the cookies are valid and the user meets the policy conditions (such as being within the expiration time), the request is granted. If not, CloudFront denies access.

Signed cookies are the best choice when: Accessing Multiple Files: If you have a group of files (e.g., a video library or a set of private documents), signed cookies can streamline the process of granting access without generating multiple signed URLs for each file. Subscription-Based Services: If you’re providing content on a subscription basis, signed cookies can be used to control access to all content behind a paywall without needing to sign each URL separately. Handling Complex Access Permissions: Signed cookies are ideal when you need to manage complex access control requirements, such as restricting access to specific content based on the user’s subscription tier or region. For example, if you are running a video streaming service with multiple subscription levels, signed cookies allow you to restrict access to certain videos based on the user’s subscription status. By generating signed cookies that specify access to multiple files, you avoid the need for individually signing each video.

Signed cookies generally suit a subscriber area or stream composed of many media fragments when changing each object URL is undesirable. The application issues the appropriate Set-Cookie headers after establishing user entitlement; CloudFront checks the signed values when the browser requests protected objects. Restrict the cookie attributes and scope appropriately, using secure transport. The server’s decision to send a cookie is an authorization step that must not be triggered merely because a browser requests an unprotected page. Test browser behavior across redirects and separate domains before assuming cookies are attached as intended.

Select the mechanism and test denial scenarios

While both signed URLs and signed cookies serve the same purpose of securing content, they are used in different scenarios: Use Case: Signed URLs are best for granting access to a single file, while signed cookies are ideal for granting access to multiple files. Convenience: Signed cookies are more convenient for managing access to groups of files, as users only need one set of cookies to access multiple resources, unlike signed URLs, which require signing each file individually. Client-Side Support: Signed cookies are automatically handled by the browser, making them more efficient for users accessing multiple files. Signed URLs, on the other hand, must be included explicitly in every link, which can become cumbersome for large amounts of content.

To make the most of signed URLs and signed cookies, here are some best practices: Set Appropriate Expiration Times: Ensure that the expiration time is appropriate for your use case. For example, signed URLs for time-sensitive content should have a short expiration time, while cookies for subscription-based content might have a longer expiration window. Restrict Access by IP or Device: Use signed URLs or cookies to restrict access based on the user’s IP address or user agent (browser or device type) to further secure your content. Keep Your Keys Secure: The security of your signed URLs and cookies depends on the security of the private keys used to sign them. Ensure that these keys are kept secure and that the permissions for accessing them are tightly controlled. AWS CloudFront signed URLs and signed cookies are powerful tools for controlling access to content and ensuring that sensitive files are protected. By providing time-limited, permission-based access, they enable you to deliver content securely while still offering flexibility for various use cases. Whether you need to secure a single file or an entire collection of resources, signed URLs and cookies give you the fine-grained control you need. By implementing these features correctly, you can safeguard your content while delivering it to authorized users quickly and efficiently.

A useful decision rule is viewer interaction. For a single short-lived installer or document, a signed URL is straightforward and works with clients that do not manage cookies. For a web experience with multiple protected assets, signed cookies are usually easier to manage. When both mechanisms may apply, CloudFront gives signed URLs precedence for requests that contain them, so a malformed URL signature cannot be rescued merely by the presence of a valid signed cookie. Test the actual precedence behavior rather than treating two authorization tokens as interchangeable.

Security testing should include a valid token, expired token, tampered path, unauthorized resource and direct-origin attempt. Record whether responses are correctly denied and what is logged for investigation without leaking usable tokens. Set expiry times in line with access policy and object-download behavior; an unusually short lifetime may interrupt legitimate large downloads, while a long lifetime increases exposure after a URL is shared. Use cached static content confidently only after both viewer authorization and origin protection have been verified. The broader CloudFront edge-caching design then determines performance rather than access eligibility.