[jimrandomh]

Many deployments of Lucene will restrict what results users can see based on who they're logged in as. For example, consider a webmail implementation which lets users search their own emails, stored in Lucene, with an index on the subject. This attack would allow someone to extract the subject lines from someone else's inbox.

[merb]

not if you have a server that handles the search box and is CSRF save. And if it isn't csrf save you don't need the timing attack since you already have the content or not.

[tshadwell]

This is incorrect. As I believe the author notes, Same Origin Policy prevents you accessing the results of endpoints you can CSRF with at least one exception (JSONP). The author uses the timing of the forged response to determine if the value was cached. Again, the attacker cannot access any information from a cross-site forged request in this case other than timing data.

[merb]

it's not. The Webserver will MOSTLY handle authentication and CORS BEFORE sending requests to Lucense / ES. Everything else is just, dumb. And wasted Resource Power. You could even use Lucene's Query engine, you just need to proxy everything.

User Input -> (CSRF / Auth) from Your Server -> Your Server -> Lucene

Most implementations will do it like that since everything else is unsafe by design, so the article is pointless.