Exploiting filepicker.io

On it! We have a new security release coming out next week that allows the use of server-side secrets to lock down both uploads and reads. We've already contacted the author and are happy to work with anyone who is concerned and get them early access

For the last couple of years I've been working on a project to index multimedia for language instruction purposes. We had to address exactly this problem- if someone intercepts your API key, which is trivial if you have to put it in JavaScript, you're screwed. The partial solution we've implemented is disallowing requests that require a key from a browser, and requiring client applications to work server-to-server in those cases.<p>It doesn't totally solve the problem, it just moves it; but it moves it to a <i>less vulnerable location</i> if you never have to get your API key into a browser where anyone can check it out by viewing source, or, in extremis, opening FireBug.

It's unfortunate to see Chris posted this without mentioning anything to Filepicker first.<p>That said, it's a pretty obvious problem which is inherent in the way Filepicker is doing things right now. Simple sometimes comes at the expense of secure. I'd argue that they made a fairly reasonable trade-off for the time.<p>Good to see Brett and the team are responding quickly.

We asked them to implement this feature before integrating in August, and they were very responsive and said they'd do it asap. My understanding is that it's now on their staging environments.<p>I don't see why anyone would have integrated without this.

S3 allows you to include a maxfile size param in your upload signature, so it should be easy enough for this to be fixed. However, you still have to be careful, as someone uploading 100 10MB files is just as bad as 1 1000MB file.

This seems like a prime example of how a startup should reply to a blog post like this. Quick, honest, and with a solution in the works.