If you sell access to premium content through WordPress — courses, photography, video, downloadable resources — you've probably already discovered the problem: your membership plugin protects the page, but the files on that page are accessible to anyone who has the URL.
A paying member can right-click an image, copy the URL, and share it. That URL works for anyone, anywhere, with no login required. The same goes for videos, PDFs, audio files, and anything else in your /wp-content/uploads/ directory. Search engines can index those files too, surfacing your premium content in image and file search results.
This isn't a bug in WordPress or your membership plugin. It's a fundamental gap in how WordPress serves media. The page is protected. The files on it are not.
There are several ways to close this gap. They differ significantly in complexity, performance, and how thoroughly they actually protect your content.
Moving Files Outside the Web Root
One common approach is to move protected files out of /wp-content/uploads/ and into a directory above the web root — somewhere the web server won't serve directly. When a visitor requests a file, a PHP script checks whether they're authorized and then streams the file to their browser.
This works, but it introduces tradeoffs. Every file download now runs through PHP, which is slower than having the web server deliver the file directly and adds load to your server. Backup plugins may not include files stored outside the standard WordPress directory structure. CDN integration breaks because the CDN can't access files that aren't publicly addressable. And if you're hosting on a managed WordPress platform, you may not have access to directories outside the web root at all.
Server-Level Access Rules (.htaccess)
Another approach is to add rules to your server's .htaccess file (on Apache) or nginx configuration that block direct access to files in /wp-content/uploads/. Requests are denied unless they come through a PHP script that checks authorization first.
This is lightweight and doesn't require moving files, but it's fragile. It only works on the specific server type it's configured for — rules written for Apache don't work on nginx, and vice versa. Managed hosting environments often restrict .htaccess modifications. Most importantly, if you use any kind of page caching or CDN, cached responses bypass the server entirely, and the access rules never execute. The protection disappears the moment a caching layer is introduced.
Signed URLs with S3 and CloudFront
For high-traffic sites, a more robust approach is to move media files to Amazon S3 and serve them through CloudFront with signed URLs. Each URL includes a cryptographic signature and an expiration time. Once the URL expires, it stops working.
This is architecturally sound, but it requires migrating your files off your WordPress server to S3, configuring CloudFront distributions, managing IAM credentials, and handling the signed URL generation in your WordPress code. It's a significant infrastructure change — effectively rebuilding your media delivery pipeline. For teams with dedicated DevOps resources, this can work well. For a solo site operator or small team, it's a substantial project to implement and maintain.
PHP-Proxied Downloads
Some plugins take a simpler approach: they generate a download link that points to a PHP script on your server. The script checks authorization, then reads the file from disk and streams it to the browser.
This protects the direct URL, but every download is bottlenecked through PHP. A 500MB video file gets read into PHP's memory and streamed byte by byte. On shared hosting, this can time out. On any hosting, it's dramatically slower than letting the web server or a CDN serve the file directly. It also doesn't protect files that are embedded in pages (like images displayed inline) — it only works for click-to-download workflows.
The Problem They All Share
Every approach above operates at the origin — your web server. They all rely on your server being the enforcement point for access control. That creates a fundamental limitation: anything that sits in front of your server — a CDN, a page cache, a reverse proxy — can serve the file without the access check ever running.
This is the architectural tension at the heart of WordPress media protection. The tools that make your site fast (caching, CDNs) are the same tools that bypass your protection layer. You end up choosing between performance and security, or building increasingly complex workarounds to get both.
The Other Problem: Per-File Management
Beyond the caching issue, every origin-based approach requires you to manage protection at the individual file level. You toggle "Protect" on each file in the media library. You attach files to specific posts and write code snippets to map folders to membership levels. You set ACLs per object in your S3 bucket. You move files one by one into a secure directory.
This is manageable when you have a dozen files. It becomes an operational burden at scale — hundreds or thousands of images, videos, and documents, each requiring explicit protection status. Miss one, and it's publicly accessible. Change your membership structure, and you're updating folder mappings and code snippets to match.
There's also a server memory constraint that's easy to overlook. When downloads are routed through PHP, the entire file must fit in PHP's memory allocation. A 10MB PDF is fine. A 200MB video course module may not be — PHP can time out or exhaust its memory limit before the download completes. Some hosting environments cap PHP memory at 128MB or 256MB, which puts a hard ceiling on the size of files you can serve through a PHP-proxied download. The more secure server-level methods (private storage, .htaccess rewrites) all ultimately funnel through PHP for authorization, and they all inherit this limitation.
How Encrypted URLs Work in XYZ Protect
XYZ Protect takes a different approach. Instead of enforcing access control at your server, it enforces access control at the network edge — before the request ever reaches your origin.
Here's how it works:
When a visitor loads a protected page, the XYZ Protect plugin rewrites every media URL on the page. Instead of pointing to example.com/wp-content/uploads/photo.jpg, the URL points to your media subdomain — something like media.example.com — with an encrypted token appended.
That token is unique to the visitor, tied to their session, and time-limited. It's generated using AES-GCM encryption, which means it can't be forged, guessed, or reused. If a visitor copies the URL and shares it with someone else, the token won't validate for the other person. If the visitor tries to use it after it expires, it won't work.
When the request arrives at media.example.com, it hits XYZ's secure protection network before reaching your server. The network decrypts the token, checks whether it's valid for the requesting visitor, and only then fetches the file from your origin and delivers it. Invalid tokens get a placeholder image or an empty response.
Your files stay on your server. You don't migrate anything to S3. You don't modify .htaccess. You don't route downloads through PHP. You don't toggle protection on individual files. Everything served through the media subdomain is protected by default — there's no per-file management, no folder mapping, and no code snippets to maintain. If a file's URL points to the media subdomain, it's protected. If it doesn't, it's public. The boundary is the URL, not a database flag or an ACL setting.
Because the protection network streams the file directly from your origin to the visitor, there's no PHP memory constraint either. A 2GB video file is handled the same way as a 50KB thumbnail — the file is never buffered through PHP's memory. The protection layer sits between the visitor and your origin, enforced at the edge, and it works with caching rather than against it.
Guard Cookie Mode: The Simpler Option
Not every site needs per-visitor encrypted URLs. If your primary concern is preventing unauthorized access rather than preventing URL sharing among authorized users, XYZ Protect also offers Guard Cookie mode.
In Guard Cookie mode, the protection network checks for a cryptographically signed cookie (HMAC-SHA256) rather than an encrypted URL token. When a visitor logs in or passes age verification, they receive a signed cookie that can't be forged with browser developer tools. Media requests through the subdomain are checked against this cookie — valid cookie gets the file, no cookie gets a placeholder.
Guard Cookie mode is simpler, faster, and compatible with page caching plugins. It's the right choice for sites where the goal is keeping non-members out, rather than preventing members from sharing direct links.
Choosing the Right Approach
The right protection method depends on what you're protecting and who you're protecting it from.
If you need to keep non-members from accessing your files, Guard Cookie mode handles that cleanly with minimal setup and full caching compatibility.
If you need to prevent even authorized members from sharing working links — because your content is high-value and you want each URL to be usable only by the person it was generated for — Encrypted URL mode is the right fit.
If you're currently using a server-level solution and running into problems with caching, CDN compatibility, or performance under load, the architectural shift to edge-based enforcement solves those issues by design.