For third party APIs we need to expose (eg. paid geolocation service, or social network integration), we've taken the approach of proxying requests through a se

For third party APIs we need to expose (eg. paid geolocation service, or social network integration), we've taken the approach of proxying requests through a server-side component. The server-side component takes requests from the client, provides some authorization and rate limiting, and passes through the request to the remote API with the secret key being stored server-side. For authenticating requests we typically check the Referer header (spoofable) and a rate limiter that aims to prevent automated queries but allow manual/regular use of the app (eg. allow 1 request per 1000ms). Where the application logic exists client-side it will never be possible to completely encrypt anything, only temporarily obfuscate. Eventually you're forced to send a request to the remote server from an arbitrary IP that can be captured and replayed. If it's your own API, and it requires authentication, then what behavior are you trying to prevent? If it's scraping, rate limiting is your friend. If it's unauthorized client creation, header checks will help (but are all spoofable). Keeping a good audit trail of requests will help to identify and close holes when they appear.