Invalid Feed Token Security Alerts

Benecaster monitors feed requests that present a token matching no subscriber at all. When the number of these failures crosses a threshold in a short window, a security notice appears in your Benecaster notification center. This page explains what the alert means and what to do about it.

---

The Alert

Title: “Unusual failed feed access on {Show}”

Body: “{N} requests for {Show} in the last 60 minutes used feed addresses that don’t match any subscriber. This may mean someone is guessing feed addresses, a scraper is probing your feeds, or a feed URL was copied incorrectly.”

Button: “What to do” — opens this page.

---

What the Alert Means

The alert counts only feed requests whose token matches no subscriber record at all. Common reasons:

• A subscriber is using an old feed URL from before their token was reset — a reset overwrites the stored token, so the old URL now matches nothing
• An automated bot or scraper is guessing feed addresses on your site
• A feed URL was truncated or broken across lines when it was copied or pasted somewhere

A revoked subscriber’s app still polling its old URL does not count toward this alert, and neither does a valid token used for the wrong show — both are classified as revoked, not unknown, and a churned subscriber’s app retrying its feed is expected behavior, not something worth alerting on. A shared feed URL doesn’t count either, since it’s still a valid request against a real token.

Stray whitespace at the ends of a copied URL — including non-breaking and zero-width spaces — no longer causes a false failure. Benecaster trims it before looking the token up, so a copy-paste artifact like that will not trigger this alert or count against the threshold.

A small number of failures is normal. The alert only fires when failures for a single show spike above a threshold in a short period, which suggests something beyond routine noise.

---

Investigating the Alert

Benecaster does not include a screen for browsing or filtering individual failed requests. What it does show you is different and narrower: on Benecaster → Subscribers, a line reading “{N} cancelled subscribers are still checking their feed” — that counts cancelled subscribers polling with a revoked token, which is a separate thing from this alert and does not overlap with it (revoked tokens never count toward this alert, as noted above).

Browsing or filtering the raw feed request log by individual attempt — to see IP patterns, user agents, or timing — is a feature of the Analytics Dashboard add-on, not of Benecaster itself. If you need to dig into who or what is generating the failures, that add-on is where to look.

---

What to Do

If it looks like a subscriber using an old URL after a reset: No action needed — the old URL is already invalid, and a fresh reset just repeats the same situation. If the subscriber is contacting you, point them to their current feed URL (Settings → GDPR/Privacy tools won’t help here; reset their token again if they’ve lost the new one).

If it looks like a bot or scraper: The requests are hitting an invalid token — by default they’re served the show’s public feed (public episodes only, HTTP 200), not a 401 or 404, and no private content or subscriber data is exposed. A request gets a 403 instead only if the show has opted into strict feed access, or the feed itself is dark. You can block the offending IP address at your hosting or CDN level if the volume is causing performance concerns. There is no Benecaster-level block list for feed requests.

If you are not sure: Contact support with the time range and show name.

---

Alert Frequency

At most one alert fires per show per 24 hours. Dismissing a show’s current alert clears its failure count and starts a one-hour quiet period — after that hour, a fresh burst of 10 failures raises a new alert. Dismissing an older alert entry for the same show has no effect on the current count or cooldown.

---

Adjusting the Alert Threshold

The default threshold is 10 unknown-token requests within a 60-minute window, per show. Developers can adjust this using the benecaster_invalid_token_alert_threshold filter, which receives the show ID so tuning can be done per show:

add_filter( 'benecaster_invalid_token_alert_threshold', function( array $config, int $show_id ): array {
    // Raise the threshold for a high-traffic show.
    if ( 45 === $show_id ) {
        $config['count'] = 25;
    }
    return $config;
}, 10, 2 );

$config is [ 'count' => 10, 'window_minutes' => 60 ] by default. count is clamped to at least 1; window_minutes to 1–1440. Return false or null to switch monitoring off entirely for that show — any other non-array return is ignored and the defaults apply. This filter does not change the 24-hour cooldown between alerts or the one-hour quiet period after dismissing one.

See the recipe Tune invalid token alerts per show for a fuller example.

---

What Is Not a Security Risk

Invalid token attempts do not expose subscriber data. A request with an unrecognized token is served the public feed (or rejected, depending on the show’s settings) before any private content or subscriber information is returned. The alert is informational — it tells you something unusual is happening, not that a breach has occurred.