Advanced Hardening: Protecting Against URL Leakage
XYZ Protect rewrites media URLs in your page HTML so that visitors access protected content through the media subdomain. However, your original media file paths may be exposed through other channels that the plugin's output buffer doesn't process. This guide covers common sources of URL leakage and how to address them.
Note: These are optional hardening measures for advanced users. XYZ Protect provides effective media protection without any of these changes. The steps below are for site operators who want to close every possible gap.
Sources of Original URL Leakage
The following WordPress features and third-party integrations may expose your original, unprotected media URLs outside of your page content:
RSS Feeds
WordPress RSS feeds (/feed/, /feed/rss2/, etc.) include the full content of your posts, including media URLs. Feed readers don't carry authorization cookies, so any media URLs in your feed are accessible to anyone who subscribes. If your protected content appears in your feeds, the original file paths may be exposed.
Recommendation: Exclude protected content from your RSS feeds entirely, or limit feeds to excerpts only. In WordPress, go to Settings > Reading and set "For each post in a feed, include" to Summary. If you use a plugin to manage feed content, ensure protected media is excluded.
XML Sitemaps
WordPress generates XML sitemaps that may include image URLs. If your sitemap includes images from protected directories, search engines receive the original file paths.
Recommendation: Review your sitemap (typically at /wp-sitemap.xml) and verify it doesn't include URLs from your protected directories. Most SEO plugins (Yoast, Rank Math, All in One SEO) allow you to exclude specific post types, taxonomies, or URLs from sitemaps. Images behind protection don't benefit from sitemap inclusion since search engines can't access them anyway.
Structured Data / LD+JSON
Many themes and SEO plugins inject structured data (JSON-LD) into your page's <head> section. This can include image URLs for article thumbnails, organization logos, and other media references. The output buffer rewrites URLs in the page body, but structured data in the <head> may use original paths.
Recommendation: Inspect your page source and look for <script type="application/ld+json"> blocks. If they contain URLs from protected directories, configure your SEO plugin to use images from exempt/public directories for structured data. For example, set your site's organization logo and default social sharing image to files in an unprotected directory.
Open Graph and Social Meta Tags
When someone shares a link to your site on social media (Facebook, Twitter/X, LinkedIn), the platform fetches the Open Graph image (<meta property="og:image">) to generate a preview. Social media crawlers don't carry authorization cookies, so if your OG image is in a protected directory, the preview will fail or show a placeholder.
Recommendation: Ensure your Open Graph images and social sharing thumbnails are stored in an exempt/public directory. Most SEO plugins let you set a default social image — use an image from an unprotected path.
Default Post Thumbnails / Featured Images
WordPress featured images (post thumbnails) appear in many contexts beyond the post itself: archive pages, category pages, search results, related posts widgets, and theme header areas. If your featured image is in a protected directory, it may show as a placeholder in contexts where the visitor is authorized to see the archive but not the individual post content.
Recommendation: Consider using public/unprotected images as featured images (for previews and listings) and reserving protected images for the post body content itself. This way, archive and listing pages show attractive thumbnails while the actual premium content remains protected within the post.
WordPress REST API
The WordPress REST API (/wp-json/wp/v2/posts/, /wp-json/wp/v2/media/) returns media URLs in its JSON responses. If your site exposes the REST API publicly (which is the WordPress default), original file paths may be accessible via API queries.
Recommendation: If you don't use the REST API for a headless frontend or external integrations, consider restricting public access to media endpoints. Plugins like "Disable REST API" or "Disable WP REST API" can limit API access to authenticated users only.
oEmbed Previews
When someone pastes a link to your site in WordPress or another platform that supports oEmbed, WordPress generates a preview that may include media from the post. These previews use original URLs.
Recommendation: If your content is premium/protected, consider disabling oEmbed for your site. Add to your theme's functions.php or a code snippets plugin:
remove_action('wp_head', 'wp_oembed_add_discovery_links');
Server-Level Hardening
For maximum protection, advanced users can restrict direct access to protected upload directories at the server level. This ensures that even if someone discovers an original file path, the server itself blocks the request unless it comes through the proper channel.
This is hosting-environment-specific and varies significantly by provider:
- Apache —
.htaccess rules can restrict access to specific directories
- Nginx —
location blocks can deny direct access or redirect to the media subdomain
- Managed WordPress hosts — Contact your hosting provider about restricting access to specific upload directories
Server configuration is outside the scope of XYZ Protect support. These are optional measures for users with the technical expertise to implement them. Consult your hosting provider's documentation or support team for guidance specific to your environment.
Restrict Protected Directories to Cloudflare IPs
You can restrict your web server to only serve protected media directories to requests originating from Cloudflare's network. All authorized media requests go through the XYZ Protect media subdomain, which routes through Cloudflare — so legitimate requests always come from a Cloudflare IP address. Direct requests from any other IP are rejected, even if someone discovers your server's IP address.
Cloudflare publishes their current IP ranges at cloudflare.com/ips. Configure your web server to only allow requests from these IP ranges for your protected upload directories. Consult your hosting provider's documentation for how to apply IP restrictions to specific directories on your server.
Quick Checklist
Use this checklist to audit your site for URL leakage:
- [ ] RSS feeds: Are protected media URLs appearing in your feeds? Switch to excerpts or exclude protected content.
- [ ] XML sitemap: Does your sitemap include images from protected directories? Exclude them via your SEO plugin.
- [ ] Structured data: Do your LD+JSON blocks reference protected image URLs? Use public images for structured data.
- [ ] Open Graph images: Is your default social sharing image in a protected directory? Move it to a public path.
- [ ] Featured images: Are post thumbnails from protected directories showing on archive pages? Use public preview images as thumbnails.
- [ ] REST API: Is the media endpoint publicly accessible? Restrict if not needed.
- [ ] oEmbed: Are preview embeds exposing protected media? Disable oEmbed if unnecessary.
- [ ] Old URLs: Were protected files previously at publicly indexed paths? See Post 8 for migration guidance.
