It was recently discovered that Sonarr does not protect Calendar feed requests when authentication is disabled. This discovery has identified a slightly misleading behaviour because the calendar feed URL appends the apikey parameter in the UI, which could lead you to assume means it can only be accessed with the API key parameter set in the URL to your Sonarr API. This is however not the case. With authentication disabled, the calendar feed path does not require anything related to the API key to access and in fact you can access it without any URL parameters at all. What is slightly more confusing is other apps like Radarr have changed this behaviour to require the API key.
While having the calendar feed URL publicly available isn't too much of an issue in terms of security (given it's read only), it does mean that anyone can use it and this might not be desirable.
Authentication should typically not be disabled in Sonarr. Even on a LAN, you shouldn't have something like Sonarr open for anything to be able to query it for various security reasons. If you have Sonarr available externally, you absolutely should have authenication enabled, otherwise someone is going to find your Sonarr installation and mess with it. The only situation where it makes sense not to disable authentication is if you implement some form of authentication in front of Sonarr such as Authelia which would mean you are using a reverse proxy.
In order to implement protection on calendar feed requests with Sonarr authentication disabled you can implement your own authentication to essentially mimic the behaviour of having a specific URL parameter and value present, but without having to turn authentication on.
Much like proxying Sonarr itself, we create a location block that matches on the calendar feed request to implement our own authentication. It uses a regex rule because there are multiple calendar feed request paths possible
Sonarr v3 implements new API/feed paths under the /feed/v3/calendar path, so this location also matches on those in addition to /feed/calendar.
The location block is case-insensitive as multiple .ics filenames are possible.
location ~* "^/sonarr/feed(/v3?)?/calendar/(Sonarr|NzbDrone).ics" {
if ($arg_apikey != <SONARR API KEY>) {
return 401;
}
proxy_pass http://sonarr:8989/sonarr/feed/v3/calendar/Sonarr.ics$1;
}
Using $arg_apikey, we can check the contents of the apikey query parameter provided by the Sonarr UI which appends this to the end of the calendar feed URL. If this URL is already in use, we can check this and make sure it does in fact have our Sonarr API key in the URL, which we have to add into nginx for checking.
Where <SONARR API KEY> is, you should add the Sonarr API key from your Sonarr installation to perform this check. If this is not present or does not match, we throw a 401 error from nginx. If successful the calendar feed path is proxied through to serve the expected .ics content.
In reality, you can use any custom URL query parameter with a value to check for, given the apikey check is completely decoupled from Sonarr at this point.
Whether or not this is changed in Sonarr v4 is undecided but this provides a way to add an authentication layer to calendar feed requests when Sonarr authentication is disabled. You could implement Basic Auth, but the issue here is many calendars that parse ics files may not be able to handle such authentication.