Practical Approaches for Securing Your Video Streams

Content protection has been a major issue since the beginning of the digital era and its importance is only growing.

Today, services like Netflix, Hulu, Amazon Video, Spotify, Apple Music etc base their entire business model on the delivery of digital media to end users. The more securely these services can protect their streams, the more secure they can feel about their revenue streams.

In this post we will review the most common methods of stream protection and explain how they can be used in combination to create a reasonably secure streaming infrastructure.

Why do I need to protect my streams?

“I have a website, I point my player to my server, and that’s it. Right?”

If only this were true.

To paraphrase Hunter S. Thompson:

“The [internet] is a cruel and shallow money trench, a long plastic hallway where thieves and pimps run free, and good men die like dogs. There’s also a negative side.”

If you didn’t already know, the internet is a wild place, full of malicious activities and circumvention. If you provide a service that can be easily copied or stolen, someone will likely take advantage of that and piggyback on your hard work (and your hosting bill) to offer the service as his own.

This would result in the following:

  • less users will visit your website to watch the content since they have other options
  • you will be paying for users to watch the content on someone else’s site
  • the users who do visit your site will experience a degraded service because your servers will be overloaded by the site that has stolen your content

It’s the perfect storm — in a really bad way for you.

Here are some examples of how you might get screwed if you’re not properly protected:

  • Another website hotlinks or embeds your content on its own site.
  • An automated program scrapes the video info from your page and previews it on an external platform.
  • Users download your content and redistribute it on other channels (share the stream URL, etc)

How To Defend Yourself

There are different methods for addressing different aspects of security and a combination of them usually provides added security.

Let’s examine them one by one:

  • Origin blocking (Origin, CORS, Referrer)
  • Embed busting
  • Tokenized URLs: Generic token
  • Tokenized URLs:Advanced user specific tokens
  • Login/Paywall
  • Stream encryption
  • DRM (Digital Rights Management)

Method 1: Origin Protection

Since every video (like every image) has a URL, in theory someone could simply copy your video URL and use it with a player of their own choice on a different site.

This means that you are now involuntary providing media services to freeloaders. They might constitute only a small portion of your traffic, but if you don’t address this issue, it might grow to leech most of your resources.

How to protect against hotlinking:

  • Block requests with an invalid referrer (nginx example, WMSPanel (Nimble) example)
  • Create a verification request (wowza example)
  • Use an explicit domain instead of * in CORS headers
    For example: Access-Control-Allow-Origin:
    Note that this will not have any effect if the browser plays the video directly and not via Javascript (e.g. HLS on Safari for iOS, DASH on Chrome for Android, etc)
    example CORS configs
  • Restrict the domains your server accepts (nginx example)

Method 2: Embed Buster

It’s pretty common to use nested frames within your page (iframe), especially to play a video, as this reduces the load time for the main page and eases deployment. With this approach, every time you want to place a video in your page, all you have to do is embed the player frame and point it to the desired video.

But what prevents a different site from taking your iframe and embedding it? Even if you don't use an iframe, you still might be vulnerable to cross-site embedding.

How to protect your page against cross-site embedding:

Built in X-Frame-Options header

If your iframe has the same domain as the parent (top) page, use SAMEORIGIN.

Use DENY if you don't want your page to be embedable by anyone.

It’s also possible to add this header conditionally based on the referrer.

X-Frame-Options: DENY
// or
X-Frame-Options: SAMEORIGIN

Javascript based embed buster

This snippet will navigate the user back to your page if someone tries to iframe you. If you place it at the very top of your page, it will make your page completely non-embedable (not even by you).

if (top != self) { top.location.replace(self.location.href); }

Method 3: Tokenized URLs

Some media servers employ a token system that blocks requests unless a specified token is provided. This token is very similar to CSRF) — it will be a cryptic hash that encapsulates certain information and will usually have a short expiry time to prevent extended usage.

Generic tokens

A common implementation for a generic token might look like this.

And so trying to get will result in 403 or other error status.

The good:

  • Time limited
  • Prevents static hotlinking

The bad:

  • Can be shared
  • Can be scraped

Advanced user specific tokens

It’s possible to create a session based token that will be more tightly locked to a specific user. While a general token might prevent direct access to the resource, a session token will prevent access to the resource outside the context of your site. The token might validate that the user requesting the stream has the same IP, User-Agent, JS generated hash and other user specific info.

That means that unlike other protection mechanisms, having the stream url will not allow the holder to view the stream.


Method 4: Login / Paywall

Another way to protect your stream is to prevent access to your stream URL in the first place.

Streams that are behind a user login and paywall are much less likely to be scraped / played externally and, when combined with user specific tokens, can provide a fair level of protection.

The Good:

  • Reduces unwanted public exposure of your stream
  • Streaming authentication is tied to an actual user session

The Bad:

  • More complex
  • Increases engagement barrier

Method 5: Stream Encryption

Also known as AES encryption, Stream Encryption means that downloaded segments are a scramble of bytes that need to be decrypted using a cryptographic key before becoming usable.

While this might sound very protective, it doesn’t provide any protection benefits in terms of content theft when used as is, and is merely an additional technical obstacle.

In HLS for example, the key is provided alongside the segments list (manifest file) which means your stream bandit can easily decrypt the segments with less than 10 lines of code.

Then what is Stream Encryption good for?

Let’s say you have a server that authenticates users and only serves the manifest file (e.g. .m3u8, .mpd) and you have all of your security mechanisms setup on that server.

Does the server that serves the actual video segments also need authentication?

By using Stream Encryption you can enforce that all users have to go through your playlist server and through the security logic residing there to get the decryption key. This means that the segment servers can operate without any special protection because the segments are not usable without the key.

Another use case for Stream Encryption would be content protection. If you are using a third party delivery service that shouldn’t be allowed to watch the content, you can encrypt the content and serve the playlist elsewhere.

If the motivation for using stream protection arises due to security while in transport, HTTPS should be used instead which will provide a secure tunnel between your servers and the end user.

Method 6: Digital Rights Management (DRM)

DRM is currently the most secure way to deliver digital content over the internet. While DRM is similar in concept to Stream Encryption, it separates the decryption key from the content and the entire decryption flow is managed in a secure black box which is not exposed to user-land and, consequently, not vulnerable to user-land hacks and breeches.

This black box decryptor is created by large companies such as Google, Apple, Microsoft etc that incorporate state of the art cryptographic tools, as well as hardware assisted decryption which renders external decryption improbable.

Common DRM products:

  • Widevine (Google) — Chrome, Firefox, Android
  • FairPlay (Apple) — Safari, iOS
  • PlayReady (Microsoft) — Edge, IE, Windows Phone

More platforms and technologies

Key points:

  • Decryption is managed by the browser
  • External license server

The problem:

  • Costs money
  • Adds complexity

A Moderately Secure Example

Let us finish with a basic implementation of a media server and a web player with multiple defense mechanisms. Nginx will be used as the media server and Clappr will be used as the web player, both of these products are available at the internet’s favorite price — free!

The implementation incorporates the following mechanisms:

  • Domain filtering
  • Referrer filtering
  • Embed buster
  • Session token
  • AES encryption

Full implementation here


Protecting streams is hard. But, if you can apply a few simple mechanisms in combination, you can protect yourself against the most common risks.

There will always be a way to steal content — for example, by capturing the screen whilst the video is playing. But, even for that scenario, some solutions start to emerge. For example, some distributors already use a watermarking technique that enables tracing leaked content back to its source, thus pointing out the culprit.

Digital content (video, music, e-books, games, etc) is becoming more and more common, so the need for protection will only grow. It only makes sense that DRM will evolve and become much more secure and much cheaper soon, so be sure to stay updated with the advancements in this subject.

DRM might not be viable for your current implementation for various reasons, but preventing hotlinking, embedding, scraping and securing transport are a must.

Originally posted on the Peer5 Blog at 2018–05–17 by Elbar



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store

Peer5 is now a Microsoft Company and available as Microsoft eCDN