🛡️ ShieldStream — Building a Secure, Piracy-Resistant Video Streaming Backend (From Scratch)

A practical guide to implementing production-grade video security using Node.js, AES encryption, and reverse proxy streaming — without expensive DRM tools.

📋 Table of Contents

1. The Problem

2. What is ShieldStream?

3. Understanding the Basics

4. Architecture Deep Dive

5. Why This Approach?

6. Alternatives Considered

7. Limitations & Future Improvements

8. Key Learnings

---

🎯 The Problem

The Real Business Challenge

Streaming a video is simple. Streaming it securely is not.

Every time a paid course, OTT episode, or private webinar goes online, there's a risk of:

• Unauthorized downloads through browser developer tools

• Link sharing that bypasses payment walls

• Screen recording and redistribution of premium content

• Revenue loss for content creators and platforms

The Industry Solution: Hardware DRM

Big platforms like Netflix, Hotstar, and Disney+ use hardware-level DRM systems:

• Google Widevine (Android, Chrome)

• Apple FairPlay (iOS, Safari)

• Microsoft PlayReady (Windows, Xbox)

But these have major barriers for indie developers and startups:

❌ Expensive — Licensing fees + integration costs
❌ Complex — Requires hardware-level integrations and CDN partnerships
❌ Closed-source — No transparency, black-box implementation
❌ Inaccessible — Not viable for hackathon projects or small teams

The Gap

What if you're building:

• An EdTech platform with premium courses?

• A regional OTT service?

• A corporate training portal?

• A proof-of-concept demonstrating security concepts?

You need real protection without enterprise budgets.

That's where ShieldStream comes in — an MVP demonstrating how backend-level video security can be implemented using accessible technologies.

---

💡 What Is ShieldStream?

ShieldStream is a Minimum Viable Product (MVP) showcasing software-based DRM concepts using production-grade security techniques.

Important: This is an MVP built for learning and demonstration purposes. It's not a final production system, but a solid foundation that demonstrates real DRM logic without enterprise-grade infrastructure.

Core Security Features

✅ AES-128 Encryption — Every video segment encrypted individually
✅ Short-Lived SAS URLs — 2-minute expiry prevents link sharing
✅ JWT Authentication — Token-based access with automatic rotation
✅ Reverse Proxy Streaming — Clients never access real storage URLs
✅ Session Validation — MongoDB tracks authorized playback sessions

What Makes It Different?

ShieldStream is NOT:

• ❌ A replacement for hardware DRM (Widevine/FairPlay)

• ❌ A final production-ready system

• ❌ A simple "hide the URL" trick

ShieldStream IS:

• ✅ An MVP demonstrating real DRM concepts

• ✅ A learning-focused implementation

• ✅ A cost-effective approach for indie developers

• ✅ A transparent system you can understand and build upon

---

📚 Understanding the Basics

Before diving into the architecture, let's understand the foundational concepts.

1️⃣ What is Video Streaming?

Traditional Download:

User clicks → Entire 2GB file downloads → User waits 10 minutes → Playback starts

Modern Streaming:

User clicks → First 10 seconds download → Playback starts immediately → Rest loads in background

Key Concept: Videos are split into small segments (typically 2-10 seconds each) and delivered progressively.

2️⃣ What is HLS (HTTP Live Streaming)?

HLS is Apple's standard for adaptive video streaming, now used industry-wide.

How HLS Works

Step 1: Video Segmentation

Original Video (movie.mp4)
        ↓
FFmpeg Processing
        ↓
output0.ts (0-10s)
output1.ts (10-20s)
output2.ts (20-30s)
...

Step 2: Playlist Creation

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:10
#EXTINF:10.0,
output0.ts
#EXTINF:10.0,
output1.ts
#EXTINF:10.0,
output2.ts
#EXT-X-ENDLIST

Step 3: Adaptive Streaming

• Player requests playlist (.m3u8)

• Downloads segments sequentially

• Switches quality based on network speed

Why HLS for Security?

✅ Segment-Level Encryption — Each chunk can be encrypted independently
✅ Browser Support — Works everywhere (Safari native, Chrome via HLS.js)
✅ Adaptive Bitrate — Automatically adjusts quality
✅ Industry Standard — Used by YouTube, Hotstar, Apple TV

3️⃣ What is AES Encryption?

AES (Advanced Encryption Standard) is a symmetric encryption algorithm — the same key encrypts and decrypts data.

How AES Works in Video Streaming

Original Segment (output0.ts)
        ↓
AES-128 Encryption (using secret key)
        ↓
Encrypted Segment (output0.ts) ← Useless without key

The Player's Job:

1. Request encrypted segment

2. Request encryption key (from authenticated endpoint)

3. Decrypt segment in memory

4. Play decrypted video

Security Benefit: Even if someone downloads all .ts files, they're encrypted without the key.

AES-128 vs AES-256

Why AES-128 in this MVP:

• ✅ Perfect balance of security and performance

• ✅ Native HLS support in all browsers

• ✅ Fast enough for real-time decryption

• ✅ Industry standard for video streaming

4️⃣ What is a Proxy?

A proxy is a middleman server that sits between clients and the actual resource.

Forward Proxy vs Reverse Proxy

Forward Proxy (Client-Side):

[Your Computer] → [VPN/Proxy] → [Internet]

• Purpose: Hide your identity from servers

• Examples: VPN, corporate proxy, Tor

• Use Case: Bypass geo-restrictions, privacy

Reverse Proxy (Server-Side):

[User] → [Backend API] → [Azure Blob Storage]

• Purpose: Hide backend infrastructure from users

• Examples: Nginx, API Gateway, ShieldStream

• Use Case: Security, load balancing, caching

ShieldStream Uses REVERSE PROXY ✅

Without Proxy (Insecure):

Playlist contains:
https://mystorageaccount.blob.core.windows.net/videos/output0.ts

❌ Problem: User sees real Azure URL → Can download directly → Can share link

With Reverse Proxy (Secure):

Playlist contains:
https://shieldstream.app/api/stream/video123/segment/output0.ts

✅ Solution: User hits backend → JWT validated → Session checked → Content streamed from Azure

Request Flow:

Client Request: GET /api/stream/video123/segment/output0.ts
        ↓
Backend validates JWT + Session
        ↓
Backend fetches from Azure Blob Storage
        ↓
Backend streams response to client
        ↓
Client never sees real Azure URL

---

⚙️ Architecture Deep Dive

System Flow Diagram

┌─────────────────────────────────────────────────────────────┐
│                        USER JOURNEY                          │
└─────────────────────────────────────────────────────────────┘

1. UPLOAD PHASE
   ┌──────────┐
   │  Admin   │
   └────┬─────┘
        │ Upload video
        ↓
   ┌────────────────┐
   │  Backend API   │
   └────┬───────────┘
        │ Process with FFmpeg
        │ • Split into .ts segments
        │ • Generate AES-128 key
        │ • Encrypt each segment
        │ • Create .m3u8 playlist
        ↓
   ┌─────────────────┐
   │ Azure Blob      │
   │ Storage         │
   │ • output.m3u8   │
   │ • output0.ts    │
   │ • output1.ts    │
   │ • enc.key       │
   └─────────────────┘

2. AUTHENTICATION PHASE
   ┌──────────┐
   │   User   │
   └────┬─────┘
        │ POST /api/auth/login
        │ (email, password)
        ↓
   ┌────────────────┐
   │  Backend API   │
   └────┬───────────┘
        │ Validate credentials
        │ Generate JWT (15min) + Refresh Token (7d)
        │ On every new login: Generate fresh pair
        ↓
   ┌─────────────────┐
   │   MongoDB       │
   │ • User record   │
   │ • Refresh token │
   └─────────────────┘
        ↓
   ┌──────────┐
   │   User   │ ← Cookies set (HTTP-only, Secure flags)
   └──────────┘     accessToken, refreshToken

3. STREAMING PHASE
   ┌──────────┐
   │   User   │
   └────┬─────┘
        │ GET /api/stream/video123
        ↓
   ┌────────────────┐
   │  Backend API   │
   │  (Reverse      │
   │   Proxy)       │
   └────┬───────────┘
        │ 1. Verify JWT from cookie
        │ 2. Check/Create WatchSession in MongoDB
        │ 3. Fetch output.m3u8 from Azure
        │ 4. Rewrite all URLs to backend endpoints
        │ 5. Return modified playlist
        ↓
   ┌──────────┐
   │   User   │ ← Receives playlist with backend URLs
   │ (HLS.js  │
   │  Player) │
   └────┬─────┘
        │ Parse playlist
        │ Request segments:
        │ GET /api/stream/video123/segment/output0.ts
        ↓
   ┌────────────────┐
   │  Backend API   │
   └────┬───────────┘
        │ 1. Verify JWT
        │ 2. Validate WatchSession exists
        │ 3. Fetch encrypted segment from Azure
        │ 4. Stream bytes to client
        ↓
   ┌──────────┐
   │   User   │ ← Receives encrypted segment
   └────┬─────┘
        │ Request encryption key:
        │ GET /api/stream/video123/key
        ↓
   ┌────────────────┐
   │  Backend API   │
   └────┬───────────┘
        │ 1. Verify JWT
        │ 2. Validate WatchSession
        │ 3. Fetch enc.key from Azure
        │ 4. Stream key to client
        ↓
   ┌──────────┐
   │   User   │ ← Decrypts segment in memory
   │ (HLS.js) │ ← Plays decrypted video
   └──────────┘

Key API Endpoints

Security Layers Explained

Layer 1: Authentication (JWT)

• Access Token: 15-minute expiry, used for all requests

• Refresh Token: 7-day expiry, one-time use, stored in MongoDB

• Token Rotation: Every login generates new pair of tokens

• Storage: HTTP-only, Secure cookies (prevents XSS attacks)

Why HTTP-only and Secure flags?

• httpOnly: true — JavaScript cannot access cookies (XSS protection)

• secure: true — Cookies only sent over HTTPS (MITM protection)

• sameSite: 'strict' — Prevents CSRF attacks

Layer 2: Session Validation (MongoDB)

• WatchSession created on first video access

• Every segment/key request validates session exists

• Sessions can be revoked instantly (delete from DB)

• Tracks user activity and watch patterns

Layer 3: Time-Limited URLs (Azure SAS)

• Blob Storage uses SAS (Shared Access Signature) tokens

• 2-minute expiry window

• Read-only permissions

• Cannot be reused after expiry

Layer 4: Reverse Proxy (URL Rewriting)

• Original Azure URLs replaced with backend endpoints

• Client never sees real storage location

• All requests pass through authentication layer

• Full control over access

Layer 5: Encryption (AES-128)

• Each video segment encrypted with unique process

• Key stored securely in Azure Blob

• Player requests key through authenticated endpoint

• Decryption happens in browser memory

---

🧠 Why This Approach?

Design Decisions for this MVP

1. Why Software DRM Instead of Hardware DRM?

Hardware DRM (Widevine/FairPlay):

• ✅ Strongest protection (hardware-backed keys)

• ❌ Expensive licensing fees

• ❌ Complex integration requirements

• ❌ Vendor lock-in

• ❌ Not accessible for learning/MVPs

Software DRM (ShieldStream MVP):

• ✅ Free and open-source

• ✅ Full control and transparency

• ✅ Easy to deploy and modify

• ✅ Great for learning DRM concepts

• ⚠️ Cannot prevent screen recording (hardware limitation)

Decision: Software DRM for accessibility, learning, and cost-effectiveness while maintaining strong backend security.

2. Why Reverse Proxy Instead of Direct Azure URLs?

Direct Azure URLs (Insecure):

https://mystorageaccount.blob.core.windows.net/videos/output0.ts?sv=2021...

❌ Problems:

• User can extract base URL

• SAS token can be reused until expiry

• No per-request validation

• Cannot track who's watching

• Cannot revoke access instantly

Reverse Proxy (Secure):

https://shieldstream.app/api/stream/video123/segment/output0.ts

✅ Benefits:

• Real storage URL completely hidden

• JWT validated on every single request

• Session checked in database

• Full audit trail of access

• Can revoke access instantly

• Can implement rate limiting

• Can detect suspicious patterns

Real-World Scenario:

Without Proxy:

User opens DevTools
Sees: https://azure.blob.net/video.ts?token=abc123
Shares link → Anyone can download for 2 minutes

With Proxy:

User opens DevTools
Sees: https://mybackend.com/api/stream/123/segment/video.ts
Shares link → Requires their JWT cookie → Doesn't work for others

3. Why JWT + Refresh Token Rotation?

Simple JWT (Vulnerable):

• Token valid for 7 days

• If stolen, attacker has week of access

• No way to revoke before expiry

• Replay attacks possible

JWT + Refresh Rotation (Secure):

• Access token: 15 minutes (short-lived)

• Refresh token: 7 days, one-time use

• New login = new token pair

• Old refresh tokens invalidated

• Stolen token expires quickly

✅ Benefits:

• Stolen access token only works 15 minutes

• Refresh token is one-time use (stored in DB)

• Can revoke refresh token anytime

• Detects token theft (old token attempted)

• Forces re-authentication periodically

4. Why AES-128 Instead of No Encryption?

Without Encryption:

User opens DevTools → Downloads all .ts files → Merges into full video with FFmpeg

With AES-128:

User downloads .ts files → Files are encrypted → Useless without key
Key requires authentication → Cannot share key (session-bound)

Attack Prevention:

• Downloaded segments are gibberish without decryption key

• Key endpoint requires valid JWT + active session

• Key cannot be shared (tied to specific user session)

• Even if key leaked, segments expire and rotate

5. Why Azure Blob Storage?

Why Azure Blob was chosen for this MVP:

This project uses Azure Blob Storage because it was already accessible through the GitHub Student Developer Pack, which provides free Azure credits for students with a valid .edu email address.

Key Benefits of Azure Blob:

• ✅ Free with GitHub Student Pack — $100 Azure credits for students

• ✅ Simple SAS Tokens — Easier to implement than AWS S3 signed URLs

• ✅ Global CDN — Built-in content delivery network

• ✅ Cost-Effective — Pay-as-you-go pricing for MVP scale

• ✅ Good Documentation — Clear SDK and API references

How to Get GitHub Student Developer Pack:

1. Go to education.github.com/pack

2. Sign up with your valid student email (.edu or school email)

3. Verify your student status (student ID or enrollment proof)

4. Access Azure and dozens of other free developer tools

Alternative Storage Solutions You Can Use:

Recommendation for Students:

• Start with Azure Blob (GitHub Student Pack)

• Or use Cloudflare R2 (10GB free forever, no egress fees)

• For learning: MinIO (self-hosted, S3-compatible)

Storage-Agnostic Architecture:

The great news is that this architecture is storage-agnostic. You can swap Azure Blob with any provider by simply:

1. Changing the storage SDK/library

2. Updating authentication (SAS tokens → Signed URLs)

3. Keeping the same reverse proxy logic

The security concepts (JWT, sessions, reverse proxy, encryption) remain identical regardless of storage provider.

6. Why MongoDB Sessions Instead of Stateless JWT?

Stateless JWT Only:

• JWT valid = access granted

• Cannot revoke before expiry

• No usage tracking

• Cannot limit concurrent streams

MongoDB Sessions (MVP Approach):

• JWT valid + session exists = access granted

• Instant revocation (delete from database)

• Track watch time and patterns

• Limit concurrent streams per user

• Full audit trail

• Detect suspicious activity

---

🔁 Alternatives Considered

1. Streaming Protocols

Decision: HLS for universal compatibility and native encryption support.

2. Storage Solutions (Detailed Comparison)

💡 Pro Tips:

For Students:

• Best choice: Azure Blob (free via GitHub Student Pack)

• Runner-up: Cloudflare R2 (10GB free forever, no egress)

For MVPs/Hackathons:

• Best choice: Cloudflare R2 (free, no bandwidth costs)

• Runner-up: AWS S3 (5GB free for 12 months)

For Production:

• High traffic: Cloudflare R2 or Wasabi (no egress fees save money)

• Enterprise: AWS S3 (most mature, best ecosystem)

• Google ecosystem: Google Cloud Storage

For Learning:

• Best choice: MinIO self-hosted (S3-compatible, full control)

• Runner-up: Any free tier above

3. Encryption Methods

Decision: AES-128 for optimal balance in this MVP.

4. Authentication Methods

Decision: JWT + Refresh for scalability and security.

---

⚠️ Limitations & Future Improvements

Current MVP Limitations

ShieldStream is software-based DRM. It cannot prevent:

Important: These are fundamental limitations of ANY software-based protection. Even Netflix with hardware DRM cannot prevent screen recording — they rely on legal deterrents (watermarking + lawsuits).

Future Improvements Beyond MVP

1. Dynamic Watermarking

What: Embed user ID/email in video frames
Benefit: Makes source of leaked videos traceable
Impact: Deters screen recording and redistribution

2. Geo-Restricted Tokens

What: Lock tokens to IP address/country
Benefit: Prevents token sharing across locations
Impact: Reduces account sharing

3. Device Fingerprinting

What: Generate unique device IDs from browser characteristics
Benefit: Limit concurrent streams per user
Impact: Prevents password sharing

4. Playback Analytics

What: Track watch patterns and detect anomalies
Benefit: Identify suspicious behavior (mass downloads, unusual patterns)
Impact: Proactive piracy detection

5. Multi-Cloud Support

What: Abstract storage layer for AWS/GCP/Azure flexibility
Benefit: Avoid vendor lock-in, optimize costs
Impact: Better scalability and reliability

6. Hybrid DRM Mode

What: Optional Widevine/FairPlay for premium content
Benefit: Hardware protection for high-value content
Impact: Best of both worlds approach

7. Rate Limiting Per User

What: Limit segment requests per minute
Benefit: Prevent automated download scripts
Impact: Slows down bulk downloading attempts

8. Content Delivery Network (CDN)

What: Distribute content globally
Benefit: Faster streaming, reduced backend load
Impact: Better user experience

---

🎓 Key Learnings

Technical Insights

1. Encryption + Access Control = Real Security

Encryption alone isn't enough. Access control and session validation are equally critical. AES-128 protects files, but JWT + session validation protects access.

2. Short-Lived URLs Are Powerful

2-minute SAS token expiry is one of the most effective anti-piracy techniques. Even if someone extracts a URL, it's useless within minutes.

3. Reverse Proxy is the Cleanest Solution

Hiding storage URLs behind an API gateway provides:

• Complete URL obfuscation

• Per-request validation

• Instant revocation capability

• Full audit trails

4. Token Rotation Prevents Replay Attacks

One-time refresh tokens stored in database prevent attackers from reusing stolen credentials. Every login generates fresh pair.

5. Software DRM Has Clear Limits

Understanding what's technically impossible (screen recording prevention) vs. what's difficult (mass downloading) is crucial for setting realistic expectations.

6. HTTP-only Cookies Are Crucial

Storing JWTs in HTTP-only, Secure cookies instead of localStorage prevents XSS attacks — one of the most common web vulnerabilities.

7. Session Tracking Enables Instant Revocation

Database-backed sessions allow revoking access immediately, unlike pure stateless JWT which works until expiry.

Architecture Insights

MVP vs Production

This MVP demonstrates core DRM concepts but would need additional layers for production:

• CDN integration

• Load balancing

• Rate limiting per user

• Advanced analytics

• Automated threat detection

The 80/20 Rule

This MVP provides 80% of the protection with 20% of the complexity/cost of enterprise DRM. For many use cases, that's sufficient.

Transparency is Valuable

Unlike closed-source DRM systems, understanding exactly how protection works enables informed decisions about trade-offs and improvements.

---

👨‍💻 Developer Takeaway

ShieldStream is an MVP demonstrating real DRM concepts using accessible tools. It's not meant to replace enterprise-grade systems like Widevine, but to teach how backend-level video security actually works.

Perfect For:

🎓 EdTech Platforms — Protect premium course content
📺 Regional OTT Services — Secure local content distribution
🏢 Corporate Training — Internal video security
🚀 Learning Projects — Understand production security patterns
🎯 Hackathons — Demonstrate full-stack security knowledge

What This MVP Proves:

✅ Software-based protection can be effective
✅ Smart backend design beats basic file hosting
✅ Accessible tools can implement real security concepts
✅ Cost-effective solutions exist for indie developers

Next Steps for Production:

• Integrate CDN for global distribution

• Add dynamic watermarking

• Implement device fingerprinting

• Build analytics dashboard

• Consider hybrid DRM for premium content

---

🔗 Technical Summary

Architecture: Reverse Proxy ✅
Storage: Azure Blob Storage (via GitHub Student Pack)
Database: MongoDB (sessions + users)
Streaming: HLS with AES-128
Authentication: JWT (15min) + Refresh (7d, one-time)
Cookies: HTTP-only, Secure flags enabled

Security Layers:

1. JWT authentication with rotation

2. MongoDB session validation

3. AES-128 segment encryption

4. Reverse proxy (URL hiding)

5. Time-limited SAS URLs (2-min)

Status: MVP for learning and demonstration
Built by: Puneet

---

💬 Final Thoughts

This MVP started as a hackathon project but evolved into a deep exploration of encryption, tokens, and secure content delivery.

It proves that indie developers don't need enterprise budgets to implement meaningful video protection — just smart backend architecture and understanding of security principles.

The goal isn't to build Netflix's DRM system, but to demonstrate how these concepts work transparently using accessible tools.

Got ideas to enhance this MVP? Drop a comment — security evolves through shared learning.

---

This is an MVP demonstrating DRM concepts, not a final production system. Always assess your specific security requirements and compliance needs before deploying video protection solutions.