Skip to content



The Peer5 service is just as secure as any traditional server-based CDN service.
Because Peer5 is a hybrid solution - which means that as a customer, you use Peer5 in combination with a traditional HTTP server - we leverage the existing security infrastructure (tokens, keys, cookies, etc) that you already have in place.

In terms of communication, there are two main communication channels:

  1. Between peers - peers are connected to each other via WebRTC data channel, which is a secure tunnel that uses the SCTP protocol over DTLS encryption.
  2. Between each viewer and the Peer5 backend - each viewer is connected to the Peer5 backend via a secure Websocket connection that uses TLS encryption.

Both channels use the industry standard network security protocol so neither the data sent between two viewers, nor the metadata sent between each viewer and the Peer5 backend can be compromised.

In addition to the above, Peer5 has a few additional security features that you can enable, based on your requirements, which are explained below.

Viewer authentication

Normally, any viewer can connect to the Peer5 backend and participate in the P2P network. In most cases this is fine, but some customers may require limiting which viewers can connect to Peer5.

Peer5 can authenticate viewers directly, in addition to any authentication mechanisms that may exist on the content provider side. The authentication mechanisms we have in place prevent unauthorized viewers from accessing content as well as any metadata that exists on the peer-to-peer network.

Domain whitelisting

The fastest and easiest way to block most unwanted viewers is by explicitly whitelisting specific domains from which viewers may connect to the Peer5 backend. This means that viewers that try to connect to Peer5 from other, non-whitelisted domains will be blocked.

Step-by-step guide:

  1. Go to your account page in the Peer5 admin panel.
  2. Add your domains (The ones where the Peer5 scripts are loaded in) in the "Referrer whitelist" box, as shown below.
  3. That's it! Any viewer that tries to connect to Peer5 with your account from a domain not listed will be blocked.

Public IP whitelisting

Another great feature for blocking unwanted viewers is by only allowing access to Peer5 from a pre-defined list of public IPs. This is similar to the "domain whitelisting" feature above, but this time we whitelist the viewer public IPs.

Step-by-step guide:

  1. Go to your deployment page in the Peer5 admin panel.
  2. Add your public IPs in the "End Users IP Whitelist" box in one of the supported formats, as shown below.
  3. That's it! Any viewer that tries to connect to Peer5 with your account with an IP that is not whitelisted will be blocked.

Supported formats:

  1. Single IP - Enter each IP in a new line, or add them one by one by clicking the "Add IPs" button after each one. Example:
  2. IP Range - Enter a start & end IP separated with a dash. All IPs within that range will be whitelisted. Example:
  3. CIDR - Enter a CIDR which represent the IP range you would like to whitelist. Example:
  4. JSON - Enter a JSON formatted array where each item in the array contains another array with two items, a start IP and an end IP. Example: [["", ""]]

You can mix & match all formats except JSON (Which must be added on its own) by separating them with a newline.

Content protection

Most platforms have multiple ways for protecting your stream from being accessed by unwanted viewers. Peer5 does not change any of those existing content protection mechanisms.
Just like without Peer5, each user will have to authenticate himself against the server, and only if authenticated successfully, will the server send the manifest file to the viewer, which in turn start requesting segments and play the stream.

Following is a list of the most common protection schemes:

Authentication on session start

In this case, every session begins with the server asking the viewer for its credentials. If these credentials are valid, the server will send the manifest file to the viewer, and the video player will start requesting segments and additional manifests from the HTTP server. Peer5 does not insert itself into ths validation process, and the viewer must pass through the same authentication gates whether or not Peer5 is deployed. Only viewers who are authorized to watch a specific stream can participate in P2P sharing for that stream, and they only share while they are actually watching the stream.

Manifest URI tokenization

Peer5 also adheres to any existing URI tokenization mechanisms that exist on the manifest level.
With Peer5, all manifest requests are sent directly to the HTTP server so validation will take place in the same manner, with the platform backend.

URI timed tokenization

In this case, the manifest URL has an additional token which encodes a few details about the viewer’s user agent (IP address, expiration time, etc). A malicious user can distribute the manifest URL to unauthorized viewers, but those viewers won’t be able to access the stream since the manifest URL is tokenized and the HTTP server will reject any validation attempts - either because of IP address or other user agent mis-matches or because of time expiration. With Peer5, all manifests requests are sent directly to the HTTP server so validation cannot be compromised.


With content encryption, users need to go through the existing authentication in place and access the decryption key. Peer5 has no access to the decryption key, and does not change the way it is being distributed and protected. We are agnostic to the content protection schemes and support standards such as AES-128.

For example, given an HLS stream that is protected with AES-128 encryption, unauthorized viewers won’t be able to watch the stream because they won’t have access to the decryption key.
The key can be sent to the end user in numerous ways - e.g., via the manifest, bundled with the page, or even requested dynamically with custom code.

Peer5 does not insert itself into this process, and the key is delivered to the video player using the same mechanism whether or not Peer5 is deployed.


The DRM use-case resembles the encryption use-case - the only difference is that the license and keys are distributed by the DRM mechanism instead of by the broadcaster. Here as well, Peer5 doesn’t interfere with the distribution of the license or keys and thus doesn’t compromise them.