Preventing direct download of audio files with amazon s3

I have audio files stored on Amazon S3, which are accessed from the music player application, as well as from mobile applications. Even unsigned users must have access to music. However, I do not want people to use the link to download content. Could this be done in s3?

thanks

+7
source share
2 answers

You can restrict access based on the HTTP referrer. It is not bulletproof (Referrer can be tampered with), but it will stop random downloads.

You use the bucket policy to limit the possible values ​​for the Referrer.

Here is an example on this page (scroll down) http://docs.aws.amazon.com/AmazonS3/latest/dev/AccessPolicyLanguage_UseCases_s3_a.html

Here is an example of them:

{ "Version":"2008-10-17", "Id":"http referer policy example", "Statement":[ { "Sid":"Allow get requests originated from www.example.com and example.com", "Effect":"Allow", "Principal":"*", "Action":"s3:GetObject", "Resource":"arn:aws:s3:::examplebucket/*", "Condition":{ "StringLike":{ "aws:Referer":[ "http://www.example.com/*", "http://example.com/*" ] } } } ] } 

You can also run signed URLs that are expiring - this will stop people from LINKING on your content from another site.

+5
source

One scenario comes to mind:

When your music player application wants to play something, it should ask your backend for the MP3 URL. Your server can create URLs with the parameter "Expires" [1] set to 10 seconds in the future.

Thus, the URL returned by your server can only be used for 10 seconds, which should be more than enough for the music player to start downloading from S3.

Of course, the user can download the file if he sees the URL of some HTTP analyzer in a 10-second window and starts the download.

But there is no bulletproof way to protect the user from receiving his / her hands from the content that their device is accessing. If content is delivered to a device, there is always a way for enough technical staff to pick it up.

ps Just heads-up, if your MP3 player supports the search (especially by sending another HTTP range request), you will have to re-get the new URL with the updated "expires" parameter from your backend.

[1] http://s3.amazonaws.com/doc/s3-developer-guide/RESTAuthentication.html

+1
source

All Articles