There are various reasons why one would need to protect a podcast feed. To name a few:
- Provide a members-only, paid-for feed
- Selling an audio-course and providing a feed as a convenient way of consumption
- Distributing sensitive audio-content in a company/group
When you plan to do this as a podcaster, you need to choose how to realise this on a technical level. Unfortunately, protecting feeds always comes with caveats, no matter how you realise it. I’m challenging you to ask yourself if maybe the most simple way of protecting a feed is enough for your needs: keep the URL private.
Not protecting your feed with technical means is not synonymous with rejecting any kind of hidden feed. Instead, you simply don’t tell anyone the feed address unless they are eligible (they paid for it etc.). Once someone has paid for access, you send them an email with a link to the feed URL.
If this system works will depend on your target group because it relies on trust. Are you selling lectures to entrepreneurs? I wouldn’t worry. Do you want to build a tight community of paid subscribers for your personal podcast? Again, I wouldn’t worry, since those subscribers have a personal interest to support you. What about gamers in their teens? Well, that could be tough 
What does it take to break the system? Either someone brute-forcing the subscription URL, which you can easily prevent by using a long random feed slug—or someone who has access to the URL and sharing it, which you cannot prevent. Speaking of sharing credentials: If you set a login and password for your feed, it’s just as easy to share it as without credentials. The Podlove Publisher also allows you to authenticate using WordPress user credentials, but even those could be shared and you would have to actively monitor feed access for abuse.
You don’t gain unbreakable security with password-protected feeds. Let’s see what issues they cause on a technical level. For one, not all podcast clients support password protected feeds, which will force some of your listeners to use a different client. Furthermore, many podcast clients do not update and parse feeds on the device but on their own servers (which helps with performance and energy consumption). Which means they need to store login credentials in plain text on their servers. That can’t be good.
How about that sensitive company feed then? The above hopefully made it obvious: Don’t use traditional feed protection methods to protect sensitive data because they are not secure. You will have to restrict feed URL access to a company network instead.
But still, as I explained in the introduction, simply hiding your feed URL is a legitimate solution in many cases. Let’s see what feed settings are relevant:
- Your feed slug should be long so the URL can’t be guessed. You can use any password generator.
- Disable the “Discoverable?” checkbox, otherwise it will appear in your website metadata.
- Disable “Allow Submission to Directories”. It will put an
<itunes:block>element in the feed, which tells directories that you don’t want your feed to be listed. It’s just a suggestion, though, and directories may ignore it.
In many instances, this approach will be good enough. I’m not saying it will work for you but you might consider it.
This article first appeared in the “Publisher Weekly” Newsletter. Subscribe to get new articles delivered to your inbox.