Related: Post data isn't available in the API until several minutes after post creation -- the same cache behavior is probably the (unintentional) cause of these bugs.

Steps to reproduce:

  • Predict the next post ID (since they're sequential, this is trivial on low-traffic sites.)

  • Query the non-existent post ID from the API using /posts/{ids}. You could also query all IDs between, say, [<id>, <id> + 100) to hide a lot of posts.

  • Immediately post something (so that it has the ID you queried for).

The API will have cached the post as not existing, so anyone who tries to view your post from the API will get an empty response for as long as it stays cached (about 5-10 minutes).

This most notably could be exploited to hide spam from third-party filters like SmokeDetector -- since SmokeDetector fetches post IDs from the real-time websocket and then requests for them in a batch, it only re-requests if it doesn't get back any posts. If one or two posts out of the batch are missing, it'll just assume they were deleted and it won't be scanned unless the post is bumped. Additionally, I reproduced this using the API demo page, so it does not require a registered API key to perform -- anyone can do this.

  • Shouldn't this be reported via stackexchange.com/about/security ? Jan 10, 2018 at 20:01
  • 2
    It's not a real security issue @JonClements - just an irritation for us.
    – Undo
    Jan 10, 2018 at 21:02
  • @Undo ah okay... just sounds like it could be used as a DoS attack is all Jan 10, 2018 at 21:03
  • @JonClements DoS, no, except in the strictest sense of the word. Worst case is you hide a post from the API for a few minutes.
    – Undo
    Jan 10, 2018 at 21:04
  • @Undo Ok... As long as there's not some strange way to lock out ids for extended periods of time I guess. Jan 10, 2018 at 21:09
  • @Kevin can you please elaborate what exactly was done? Or not exactly? Jan 11, 2018 at 16:39

1 Answer 1


As of the latest deploy, the API will no longer honor empty cached results if the method looks up the returned type by it's id (a method that returns posts by post_id, for example).

Additionally a fix went out to address a query pattern that could result in a cached result living longer than intended.

  • Just curious - how long ago did the API start caching empty results? We've only noticed this recently.
    – Undo
    Jan 11, 2018 at 16:43
  • It's always been possible for empty results to be cached, but as with all caching it's somewhat non-deterministic - I don't know exactly what pushed it from "possible" to "common" recently. Jan 11, 2018 at 16:45

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .