A signed URL can restrict access to a video, but it does not authenticate the person who presents it. First authenticate the viewer and check their entitlement in a trusted service; then issue scoped credentials and make sure the delivery service enforces them across the manifest and every media request.
That distinction matters for HLS and DASH. A player may fetch a manifest, video and audio segments, alternate renditions, and later retries as separate requests. Protecting only the first URL does not necessarily protect the rest.
Why adaptive video needs request-level protection
A downloadable MP4 is often requested as one resource, sometimes with additional range requests. Adaptive streaming is different: an HLS or DASH manifest describes media resources, and the player requests those resources as it plays. It may also switch between quality levels, select another audio track, or retry a failed segment. The exact request sequence depends on the packaging and player.
Treat the playback session as a set of requests, not a single link. Your access rule needs to cover each file the player is allowed to fetch: the manifest, media segments, alternate renditions, and any other protected assets it needs. A rule that protects one URL while leaving the rest public can expose the media; a rule that protects the manifest but fails to authorise its segments can make playback stop as soon as the player needs them.
A signed URL is a bearer credential. Anyone who gets a copy can use it while it remains valid and within its configured scope. It is not proof that the person making the request has just logged in, paid, or remained a member. Avoid placing long-lived links where they might be shared or retained in logs, and use HTTPS when issuing credentials.
This is access control, not digital rights management. It can prevent requests that lack valid credentials, but it cannot stop an authorised viewer from recording or redistributing video after it has been decoded. If you are securing a church or community broadcast workflow as well as its playback, the guide to securing a YouTube live-streaming setup covers a different set of account and broadcast risks.
Authenticate the viewer and check entitlement
Put the decision about who may watch in a trusted application service. When someone asks to play a video, verify their login and check the relevant entitlement: for example, a purchase, an active subscription, a membership, or an access grant from an administrator. Do not treat possession of a video identifier or a URL as proof of entitlement.
If the check succeeds, a trusted backend or managed signing service can issue a credential for the media delivery layer. The browser or app should receive only the resulting credential, not a private signing key or provider API secret. If signing logic and its secret are shipped in client code, a user can inspect the application and reuse that secret to generate credentials.
Keep the authorisation decision and the delivery mechanism distinct. The application decides whether this viewer may watch this video now. The CDN or hosted video service checks whether each incoming media request carries acceptable proof. That second check must apply to the actual requests generated by the player, rather than only to the page where playback starts.
You can also revoke access at the application level by declining to issue fresh credentials after a subscription ends or an account is disabled. A credential that has already been issued may remain usable until it expires or the provider invalidates it, depending on the system. Plan for that gap rather than assuming an entitlement change immediately cancels every link in circulation.
Choose signed URLs or signed cookies
A signed URL places a signature and policy information in the URL. It works well for a single protected object, a download, or a client that cannot use cookies. But a player making requests for many files needs each requested URL to be accepted by the delivery service. You may need to sign or rewrite URLs for segments and renditions, and make sure generated URLs remain correct when the player changes quality or retries a request.
A signed cookie can authorise a set of requests without adding a separate signature to every media URL. It can suit a browser player that fetches several protected files from a common path or domain, provided the browser and player send the cookie on all relevant requests. That support should be tested in the actual browsers and native players you intend to serve. Cookies can also be awkward across domains, embedded players, or clients with limited cookie handling.
Some providers offer prefix-scoped policies or a managed video token. A prefix can cover a family of media files, but should be no broader than the set the viewer needs. A managed token may reduce the amount of signing and delivery configuration you maintain, though its expiry rules, download controls, player integration, and available restrictions are provider-specific. Read the current provider documentation before choosing.
| Pattern | Often fits | Main trade-off |
|---|---|---|
| Signed URL per file | One object or a client without cookie support | Every protected request needs an accepted signed URL; cover all referenced files. |
| Signed cookie | A player needs several protected files and sends cookies reliably | Fewer rewritten URLs, but cookie behaviour varies by player and browser. |
| Prefix-scoped policy | Media files share a narrow URL path and the provider supports prefix rules | Convenient for a set of files, but an overly broad prefix grants excess access. |
| Managed video token | A hosted video service provides tokenised playback | Less delivery plumbing to manage, with provider-specific controls and constraints. |
Choose by mapping the playback requests your player makes, not by choosing the shortest example in a provider guide. Consider whether the player supports cookies and redirects, whether URL rewriting is required, how the token behaves on retries, whether credentials can be refreshed, and how you will restrict direct access to the origin. A small site serving a single private recording may prefer per-file links; a catalogue of adaptive streams may be easier to manage with a tested cookie or token policy. Neither pattern is best for every client.
Scope and expire credentials
Limit a credential to the video or narrow group of media objects needed for one viewing session. If the provider supports URL prefixes, paths, IP ranges, or geographic conditions, use only controls that fit your audience and client behaviour. Restrictions can reduce accidental sharing, but may also block legitimate viewing when a viewer's network changes or the client does not meet the condition. Provider syntax and enforcement differ, so validate the current rules for your service.
Choose an expiry that limits the usefulness of a copied credential without ending a normal viewing session unexpectedly. A token that is too short can fail during buffering, a long programme, network recovery, or a later segment request. A token that lasts much longer than needed extends the window in which a copied bearer link can be reused. Support refresh when appropriate: the authenticated player asks the application for new credentials, and the application checks entitlement again before issuing them.
Do not assume expiry is evaluated only when playback begins. A delivery provider may check each HTTP request, so a later segment or byte-range request can fail after the credential expires even if an earlier request began in time. Allow for client and service clock differences where timestamps are involved, and test what happens when a session reconnects near expiry.
Keep signing keys and API credentials on the trusted side of the application boundary. Restrict who can use them, rotate them according to the provider's supported process, and avoid exposing full tokens in analytics, browser history, support screenshots, or application logs. Deliver credentials over HTTPS. If a signed URL includes required query parameters, sign the exact URL and follow the provider's rules about later changes; modifying a signed URL can invalidate it.
Cover manifests, segments, and renditions
Start by listing the resources that make up a playback session. For HLS, that can include a master playlist, variant playlists, media segments, and alternate audio or subtitle resources. DASH uses a manifest and references media resources in its own format. Packaging choices vary, so inspect the actual output rather than relying on a generic file list.
Then verify how credentials reach each request. With per-file URLs, confirm every manifest reference resolves to a signed resource, including alternate renditions and any files requested after a quality switch. If manifests are generated dynamically, make sure the signing or rewriting step applies to their references as well. A valid signature on a manifest URL alone does not establish that subsequent segment requests are authorised.
With cookies or a prefix policy, check that the policy covers all required paths and that the client sends the credential to each one. A cookie scoped too narrowly may allow the first playlist but block segments in a different directory. A prefix that is too broad can grant access to unrelated videos. Use the narrowest common scope that covers the resources the player actually needs.
If you use a hosted video service, follow its tokenised playback model for both HLS and DASH, and confirm which URLs the token authorises. For example, Cloudflare Stream documents signed tokens for HLS and DASH playback and a setting that can require signed URLs. Those are Cloudflare-specific behaviours, not a general rule for all video services; consult the Cloudflare Stream signed URL documentation for current details.
Protect the origin as well as the CDN path. If a storage bucket or media server remains publicly reachable, a viewer may request the object directly and bypass the CDN's authorisation policy. Restrict origin access where feasible and verify direct-origin requests are denied. For HLS delivery, AWS recommends signed cookies when access is needed for multiple restricted files; its CloudFront signed URL and signed cookie guidance explains its own controls and request behaviour. Google also describes signed cookies and URL prefixes for adaptive streaming in its Cloud CDN signed request documentation.
Test authorisation and access failures
Test with the real player types you support: desktop browsers, mobile browsers, and native applications if relevant. A command-line request can confirm a particular URL's response, but it cannot prove that a player sends cookies correctly, follows redirects as expected, or handles a token refresh during playback. Test a complete session, including a rendition switch and a reconnect where the player makes fresh requests.
Use a small matrix of cases:
| Test | Expected result to verify |
|---|---|
| No login or entitlement | The application does not issue playback credentials. |
| Valid entitlement and credential | Manifest and required media files load and play. |
| Expired credential | New protected requests are rejected, and the refresh path behaves as intended. |
| Altered path, query, or token | The provider rejects requests that no longer match the signed policy. |
| Direct request to origin | Access is denied if the design relies on CDN enforcement. |
| Alternate rendition or later segment | The request remains covered by the chosen policy. |
When a test fails, inspect the failing request, not just the initial playlist. Check its path, query string, response status, cookie presence, expiry, and whether the request went to the CDN or origin. A 403 on a later segment may be caused by a missing cookie, a policy path that misses that rendition, or an expired token. A public response from the origin points to a different failure: the delivery control can be bypassed altogether.
Build this testing into changes to packaging, domain names, player configuration, and token policy. A new rendition directory or alternate audio path can escape an old scope. If your content is part of an always-on YouTube workflow, the reconnection guide for a dropped YouTube radio stream addresses broadcast recovery; it does not replace request-level access checks for a private HLS or DASH player. Similarly, a church live-streaming setup guide can help plan the production side, while the controls here apply to viewers fetching protected media.
For a service whose specific pain is keeping an uploaded programme available as an always-on YouTube broadcast without leaving a computer running, StreamNeo handles that separate broadcast task; it does not replace the entitlement and playback controls described here.
Before committing, compare the operating options on the pricing page. When the file and channel are ready, start free — 24-hour trial, no card.
FAQ
Does a signed URL authenticate the viewer?
No. It is a bearer credential: a person who obtains it may use it within its configured scope and validity window. Authenticate the viewer and check entitlement in your application before issuing it.
Is protecting the manifest enough for HLS or DASH?
Not necessarily. The player makes later requests for segments, renditions, and sometimes other assets. Ensure your URLs, cookie, prefix policy, or managed token authorises every required request, and test the player rather than assuming the manifest signature covers them.
Should I use signed URLs or signed cookies?
Use signed URLs when individual resources need credentials or the client cannot reliably send cookies. Cookies can suit a player requesting many files when cookie handling works across all the clients you support. Compare the actual request paths and test both access and expiry behaviour before settling on a pattern.
Do signed links prevent recording or sharing?
No. They restrict who can fetch media while the credential is valid, but do not prevent an authorised viewer from capturing decoded playback. Keep scopes narrow and expiry appropriate, and treat recording protection as a separate requirement.