Eugene Gorelikov

The proper solution is for the issuer of the API key to restrict use of that key to a specific domain.

This is what we are going to do with our API keys, however the real problem here is that it appears Google service API keys for server to server communication (which users will be required to provide) cannot be restricted to a domain or IP. Perhaps Google didn’t think that these keys could be used in a CMS module, so in this case Google API misses a critical feature.

I guess the topic can be considered as resolved. I appreciate everyone’s input.

Thank you for your input, bcworkz.

Obviously this is a major possible exploit. I’m not talking about my particular case. More and more plugins out there use the api key/token for access to some ‘premium features’ and it looks like their access creds are all compromised. Obviously you cant just tell the users to not to use some hacked or nulled plugins, because sometimes they just hire a developer who installs them.

Is it possible to somehow raise this issue with core dev team? It wouldn’t be THAT difficult to change the way options are registered and used. It would be relatively easy to add a column private (varchar) to wp_options and when this column value is empty then the option behaves in a normal way and is accessible by any plugin. If private contains the slug of a plugin that registered this option, then only this plugin would be able to access option value.