Take Twitter keys for example (the most shared secrets, according to the article). Instead of hard-coding the secret in the app, just implement the Oauth authentification as it should be done: You store the secret key on your server, and issue the get request token from your server, then redirect the user to Twitter authorization page, instead of issuing the request to twitter from the app itself.
You will say: why should i do that if an attacker could just issue requests to my server and still get credentials using my app credentials? Here are some reasons:
1. You now have control over accepting the requests or not (ban ips, etc). If your app is pretty popular, spammers may try to use your app credentials to interact with Twitter as you will have a better reputation than newly generated credentials.
2. If your key is disabled by twitter for abuse, you can replace it with a new one without having to update the app itself.
1. You now have control over accepting the requests or not (ban ips, etc). If your app is pretty popular, spammers may try to use your app credentials to interact with Twitter as you will have a better reputation than newly generated credentials.
2. If your key is disabled by twitter for abuse, you can replace it with a new one without having to update the app itself.
This applies to the other services too.