Keep users from downloading or scraping your website media

Protect images, videos, audio files, and more!

Imagine you’re running a photography website. You spend a lot of time pouring your blood, sweat, and tears into a stunning portfolio. You want to share your work with the world on the Internet, but that doesn’t mean you want them to have access to download the files for their own purposes. Thankfully, with Amazon AWS services, you can have the best of both worlds! These powerful tools allow you to protect your media files from being downloaded, or even accessed at all from anywhere besides the exact places you specify. Even if you don’t have a photography website, if you have any assets you want to protect on your site, AWS can achieve what you’re looking for.

Create your bucket in Amazon S3

The first step is to use Amazon’s S3 storage services to create a “bucket” for your assets. Then start uploading! Just be sure to configure the bucket’s policy to block public access, for later.

Who knows, you may like S3 enough that you want to use it to provide all of your website’s media, even those you don’t want to necessarily keep behind lock and key. You’d go about this by creating sub-buckets within your main bucket, and setting up the following rules for the protected bucket and allowing public access for all the rest. Unless you’d rather just protect the entire site’s assets, of course.

Grant permissions to a Cloudfront OAI

Now, if you tried to access a protected file in your S3 bucket directly, it would require several URL parameters to authenticate the request and grant permission. Oftentimes, this permission would just be temporary, too. This isn’t practical for embedding on your website – especially since a user can see the link and copy all the URL parameters. Those authentication tokens are all that’s required at this point – and going through the process to hide or encrypt them is unideal from several standpoints.

That’s where this next tool, Cloudfront, comes into play. Cloudfront is a CDN tied to Amazon’s services, making it ideal for serving media from S3 buckets. More than that, Cloudfront allows you to create an “Origin Access Identity,” essentially making it an authenticated user for the S3 buckets and removing the need for a bevy of URL parameters in order to access protected assets. Follow these steps to set up an OAI for your protected bucket in the previous steps

Set up access rules via WAF Web ACLs

When setting up the Cloudfront OAI, you likely saw a setting to select a Web ACL (access control list). This will be the meat of the protection: using Amazon’s WAF services, you’ll be able to create a ruleset for the Cloudfront OAI behavior, whether it should allow or block the request for resources in your bucket. You can go back and add the rule to the OAI after setting up the ACL, you don’t have to wait to create the OAI.

In our particular use case, we want to only allow requests from our website, and stop everything else. The best way to do this is to set up a rule based on a single header, “Referer,” and require it contain the main part of your website (example.com). Allow these request, and set the default action to block.

This is all we need for this scenario, but you can go to a much deeper level as well. Set up rules based on IP address, other headers that you configure and/or encrypt, or even something in the body of request JSON. We’re staying at a fairly low technical level for this tutorial, but you can go much deeper with Amazon’s powerful tools.

And the result…

So, you’ve uploaded all of your assets into an S3 bucket. You allowed access through a Cloudfront OAI, with some ACL rules associated to only allow through your website. The result? Your website assets have a new layer of protection! Even though users can see the link to the asset, trying to navigate to the link themselves will return a 403 “Forbidden” error. The same will happen if they try to take that link and embed it on their own site: nothing. The only way for the user to see the content is when it’s served on your specified website. It’s not a bad idea to try to disable downloading too, just to be safe.

Of course, those who are truly dedicated will always find a way. There’s no way to prevent a user from taking a screenshot or recording their device’s visual and audio output. But those are generally low-quality solutions, and require a measure of effort that the casual user won’t want (or even necessarily know how) to go to. There’s no way to 100% lock down content that you want the public to be able to see – but you can take these steps to make it significantly harder.

Need help protecting your website’s media, or setting up other AWS services? Don’t hesitate to reach out for a free quote today!