Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Hardcoding your AWS stuff is nasty, because any bored script kiddie can extract it and make spurious requests, and at the end of the month you receive a larger-than-usual bill.

But Twitter API keys? These just allow access to the Twitter API. If these are leaked, the biggest risk is a denial-of-service of rate limits by a third party, which Twitter may catch and revoke the account. The developer will then have to create a new credential and update the app for it to keep working.

In this day and age where mainstream apps update often too, I doubt this is seen as a serious risk, for the long tail of apps. If this approach obviates maintaining Backend-as-a-Service proxy the developer pays out of their own pocket, it can be more cost-effective.



Somebody can abuse the backend as a service as well, so proxying access to something like Twitter doesn't help that much.


Is it that hard to setup a BaaS lambda function that just increments a DB field and checks it before making the Twitter call to rate-limit users? Even outside abuse I'd want to be able to rate-limit my API actions to the realm of stuff humans can do to keep out bots


There is a little more control, and you can setup limits for users. This prevents a wide leak of an API key.


I think that the risk arises from the bad practice of hardcoding any keys in your mobile app. Hardcoding Twitter keys can extend to AWS or say Stripe for example, which can lead to serious security breaches. This post could be meant to warn developers against using this practice going forward, and like others have suggested, storing third party credentials server-side, making the call on behalf of the client app and then returning the results to the client.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: