How to protect video content with signed URLs

The video was supposed to be behind a login. Instead, it ended up embedded on someone else’s website.

A developer at an edtech company told us how it started with a simple course launch, paid video lectures, some produced in-house, others licensed from creators. Users had to log in to watch. But within weeks, links to their premium content started showing up in unexpected places:
First in WhatsApp groups. Then on Reddit. Then fully embedded inside a third-party blog running affiliate ads.

The backend didn’t break. There was no exploit.
The real issue? They were serving video through static URLs.

No expiry. No access check. Once someone had the link, from a browser’s network tab, or just copy-pasting, it was valid everywhere. Anyone could play the video directly. There was no way to tell who watched, when, or from where.

They plugged one hole, and another appeared. Until the video was everywhere but their platform.

That’s when they noticed something worse:

Their bandwidth costs were going up, but user sessions weren’t. Turns out, their video player was being hotlinked on a high-traffic education forum. Thousands of students were watching the course, on someone else’s site, with their CDN paying for it.

This is hotlinking at its most frustrating. Not only do you lose control over where your video is watched, you also lose visibility, monetization, and still pay the infrastructure bill. It’s like someone siphoning your fuel to drive their car, while charging it to your account.

And it’s not rare. We’ve seen the same story play out in fitness apps, internal tools, even pre-release media review portals. If your video URLs are exposed and unauthenticated, it’s only a matter of time.

‍

What are signed URLs?

A signed URL is a normal video URL with a time-sensitive signature attached. The signature is generated on your backend using a secret key. When the request hits your video origin (CDN, storage layer, or video API), the system validates the signature.

If it checks out, meaning it hasn't expired, and the signature matches the content is served. Otherwise, it’s rejected.

You can also include other parameters in the signature like user ID, IP address, or headers to make the access more specific.

‍

Why static URLs are a problem

Most teams start by serving videos through a basic link, maybe even with a login gate. But here’s the issue: once that link is exposed (through browser dev tools, a network log, or someone pasting it in a chat), it can be reused by anyone.

It’s just a URL. It doesn’t care who’s asking.

That creates two problems:

1. No access control after link generation If someone copies the URL, it works indefinitely (or until you manually revoke it or rotate it).
2. No usage context You can’t control or track who used it, when, or from where.

Signed URLs solve this by baking access logic into the URL itself. It becomes a one-time, time-limited, rule-bound token.

‍

How signed URLs work (under the hood)

Here’s the common flow:

1. A user requests a video (e.g. clicks play on your frontend).
2. Your backend checks if that user is allowed to access it.
3. If allowed, you generate a signed URL that includes:
   • The video path or resource identifier
   • An expires_at timestamp
   • Optional parameters like user ID, IP address, or headers
   • A cryptographic signature (HMAC or JWT, usually)
4. You return that signed URL to the frontend player.
5. The player uses that URL to request the video from your CDN or video API.
6. The origin verifies the signature and enforces the rules:
   • If it’s expired → blocked
   • If the IP doesn’t match → blocked
   • If the signature is invalid → blocked
   • If everything is valid → video streams

This logic runs entirely at the edge or in the origin service. No need to maintain sessions or auth state between requests.
‍

How to build signed URL support into your app

At a high level, you only need a few things:

1. A secret key: Shared between your backend and the video origin (CDN, object store, or video API).
2. A signing function: Code that takes a video path, an expiry timestamp, and optional constraints (IP, user ID, etc.), then outputs a signed URL.
3. Validation logic on the origin side: A system that can verify the signature and enforce the access rules before streaming the video.

Let’s break that down with a basic example:

‍

# Pseudocode example
import hmac, hashlib, base64, time

def generate_signed_url(video_path, secret_key, expiry_seconds=600):
    expires_at = int(time.time()) + expiry_seconds
    raw_string = f"{video_path}:{expires_at}"
    signature = hmac.new(secret_key.encode(), raw_string.encode(), hashlib.sha256).hexdigest()
    
    return f"{video_path}?expires={expires_at}&sig={signature}"

‍

This works if:

• You’re self-hosting videos
• Or using a CDN that supports signed URL validation

Then you configure your CDN or media server to reject any request where the signature doesn’t match or the timestamp is in the past.

‍

Why this gets harder in production

At first glance, it feels like a few lines of HMAC signing and you’re good. But as traffic scales, edge cases start stacking up.

Here’s where teams get stuck:

1. Clock skew: If your CDN’s clock and your backend clock differ even slightly, URLs may expire early or stay valid longer than expected.
2. Multi-device / IP flexibility: Users switch networks or devices. If your signatures are too strict (e.g. IP-bound), you’ll break valid sessions. If they’re too loose, abuse slips through.
3. Token reuse: If you don’t scope signatures tightly (e.g. per session or user), a shared token could still give access to others.
4. CDN compatibility: Not all CDNs support custom signature validation out of the box. You might have to add a lambda@edge, Cloudflare Worker, or custom logic at your media origin to validate tokens.
5. Revocation: You can’t easily revoke a signed URL once it’s been generated. If a user gets banned or a purchase is refunded, the token still works until expiry, unless you build a database layer to blacklist tokens (which defeats the purpose of stateless access).
6. Device-level restrictions: If you want to prevent casting, downloads, or playback on jailbroken devices, signed URLs won’t help. That’s where DRM comes in, and it’s a whole different level of complexity.

You can build your own signed URL system and for many apps, it works fine at low scale. But once you're dealing with real traffic, multiple content types, and platform integrations, managing security, expiration logic, and CDN behaviour becomes a constant overhead.

That’s why a lot of teams end up offloading this to a video API like FastPix.

‍

Can signed URLs be bypassed?

Yes, here are the most common ways signed URLs get misused and what you can do to avoid them.
‍

1. Shared links that outlive their purpose

A signed URL is only as good as its expiration window. If it’s valid for too long, it can easily be shared, and it will work just fine until it expires.

This is especially common in:
‍

Subscription apps:

A fitness app gave paying users access to premium HIIT workouts. Once a subscriber clicked play, the app generated a signed URL valid for an hour. But users quickly figured out they could copy that link from the browser and send it to friends. Since the URL still worked for 60 minutes, even outside the app non-subscribers were watching full videos for free, with zero tracking or usage data attached.
By the time the team caught on, some workouts were being streamed from 10+ different IPs per session.

Pay-per-view events:

An event streaming platform sold virtual tickets to a live concert. Each purchase generated a signed URL with a 2-hour expiry, long enough to cover the event. But the same link was reused across devices: someone paid once, then streamed the show on a laptop while casting to a TV, and even shared the link with friends.  Dozens of viewers with one ticket.
‍

What to do instead:
Keep the lifespan short, 5 to 15 minutes is usually enough. If possible, scope the URL to a specific IP, device ID, or user session. FastPix supports short-lived, per-playback URLs by default, so you’re not relying on static links.

‍

2. Bots scraping links from your frontend

If a signed URL appears in your HTML, your JavaScript, or even your API responses, it can be scrapped. Once it’s scraped, it can be reused, embedded, or posted, and you won’t even know it happened.

What to do instead:
Hide URLs behind a server-side token check. Or make them one-time use. At minimum, use referer checks to ensure playback only works from your own domain. FastPix supports secure token-based playback requests that require server-side approval before any URL is issued.

‍

3. Loose or incomplete signing rules

Sometimes teams implement signed URLs, but forget to lock down the details:

• Expiration is set to hours or days
• No IP or user constraints
• CDN isn’t actually validating the signature

In these cases, signed URLs offer the illusion of security, but functionally behave like public links.

What to do instead:

Make expiration tight. Validate every request. Use a shared secret that’s rotated periodically. FastPix lets you define custom access rules on each playback session, so you can match the level of restriction to the use case without hardcoding logic into your player.

‍

Built-in signed URL security with FastPix

Most teams end up cobbling together URL signing, access checks, and CDN rules themselves, and spend more time maintaining edge cases than enforcing actual security.

FastPix handles that for you, with token-based playback and security rules built into the platform:

• Short-lived URLs by default
  All playback links expire quickly. You control the TTL, from minutes to hours, depending on how tight you want access to be.
• IP and session binding
  Signed URLs can be scoped to a specific IP, device, or session. If the context doesn’t match, the stream doesn’t start.
• Role-aware access control
  Easily enforce rules like: free users can stream SD, paid users get HD, internal users access draft videos. No custom logic needed.
• Custom domains, same protection
  Deliver signed URLs from your own domain without weakening security. The enforcement happens under the hood.

Every FastPix playback request is validated server-side using a signed token.

‍

Strengthen signed URLs with layered controls

Signed URLs are only as secure as the rules behind them. If they’re too permissive, long-lived, shareable across devices, or open to scraping they’ll fail quietly. Here’s how to tighten them up with practical constraints that actually hold up in production.
‍

Short-lived tokens: Keep the access window narrow

If your URL is valid for hours, it will get shared, and used beyond the intended session. This is the most common failure.

What to do:
Set a short expiration window, usually 5 to 15 minutes is enough. FastPix playback URLs expire quickly by default, and you can adjust the TTL based on session duration or user type.

IP and session binding

A signed URL should only work for the user who requested it. If it works from any IP or device, it’s easy to pass around or replay.

What to do:
Scope each token to the user’s IP, session, or device fingerprint. FastPix lets you tie playback to an active session, so copied links won’t work elsewhere.

Referrer validation

One of the easiest exploits is embedding your stream on an unauthorized site. If you’re not checking referrers, your content can be hijacked and played from anywhere.

What to do:
Set up a referrer whitelist. Only allow playback from your own domain or app. FastPix blocks access automatically if the request doesn’t match your expected origin.

User-agent filtering

Scrapers and download tools often identify themselves (or try to spoof common agents). If you’re not checking user-agents, your videos are an easy target for automation.

What to do:
Deny access to known bots or suspicious headers. FastPix supports user-agent filtering, so playback is limited to real browsers or devices you trust.

Token fingerprinting

Even with all of the above, someone might still try to leak content, by screen recording, sharing accounts, or distributing download links.

What to do:
Embed user or session IDs directly into the token. That way, every playback request is traceable. If you detect abuse, you know exactly who leaked it, and can revoke access immediately.
‍

One thing to keep in mind: security shouldn’t get in the way of real users

Go too strict, and you’ll block real users. Go too loose, and your content ends up everywhere. The hard part isn’t locking things down, it’s doing it without breaking playback for people who are supposed to be there.

Overly aggressive rules like tight IP checks or short-lived tokens can cause issues when a user switches networks or resumes playback later. But if you skip access control entirely, signed URLs become public links with a time limit easy to share, easy to exploit.

FastPix gives you control without the overhead. You can scope tokens to sessions, bind them to IPs, adjust expiration times, or embed user identifiers, all depending on what your app needs. Whether it’s one-time rentals, live events, or subscription content, you can tune the level of protection without blocking real viewers.

The result: security that holds up in production, without getting in the way.

‍

Final words

You’ve got your content, your users, and a business that depends on keeping both secure. Signed URLs are a solid first step,  but configuring them, rotating them, and patching the gaps takes time. FastPix handles it for you: short-lived tokens, session binding, leak tracking, all built in and ready to use.

Want to see how it works in practice? Sign up and get started with free credits. Or just reach out, we’ll help you lock it down without slowing your users down.

‍