The case for signed URLs
In this chapter we'll discuss when signed URLs are used and why the serveless model requires a new way of handling files. Then we'll move on to the technical details of how AWS services implement secure file handling.
Use cases
The primary use case for signed URLs is to serve non-public files stored in an object store (in AWS's case, S3). These can be videos for a subscriber-only video course, PDF files for an ebook, audio files for a member-only podcast, avatar images uploaded by the users, pictures sent in a private chat room, or anything similar. The important points are that they are files, and they are available only to some visitors (require access control).
For public files that don't need access control you don't need signed URLs. In that case, you can just make them available on a fixed URL. URL signing is only useful for non-public files.
Most applications are divided into a frontend and a backend. The former is usually a webapp running in a browser and the latter is a function running inside the cloud, for example, a Lambda function. Behind the backend, there is a database as well, in a serverless environment that can be DynamoDB or RDS. The backend uses the database to decide whether the client has access to the file or not.
On the frontend, the signed URLs can be used just like any other ones. They can be embedded inline, such as images on a page or a video that is played inside the browser, or they can be downloaded.
The security of the signed URLs is determined by the authorization check your API does (step #3 on the image above). Signing the URL means you give access to the file.
The fact that you use signed URLs does not automatically render your data more secure.
The typical use-case when it comes to private files is distributing PDF files to users who bought an ebook. In this scenario, non-public files are distributed to users based on their status (bought/not bought).
A similar example is a video course. In this case, instead of PDF files, users are downloading a much larger amount of data in a controlled way.
Another example is when users can upload avatar images and only some users can download it. This can be part of the implementation of a social network or any other platform that lets users manage their own profile and determine who can see it.
A more involved example is a chat room where participants can upload any type of files and only the people inside the room can download them. Similarly, an issue tracker that allows arbitrary attachments also requires a way for controlled upload and download of files.
While CloudFront signed URLs allow protecting not just files but any path, in theory you can restrict access to APIs with signed URLs as well. While it's a possibility I'm yet to find a good use case for that. All the examples in this book protect only files with signed URLs.