Key security

8 posts / 0 new
Last post
Key security

It appears that the Mapquest API keys are semi-permanent keys and thus cannot be handed out to a browser securely.

Is this correct or am I missing something?   S3, Mapbox, and other APIs allow creation of temporary tokens that allow temporary access to the browser so that the browser can directly fetch information from the server.

It seems to me what I'll have to do is store the keys on the server and create a proxy service on my server to add the securely held keys.  (I'm primarily doing reverse geocoding).  Is that correct?

MapQuest has permanent keys,
MapQuest has permanent keys, not temporary tokens. If needed, the browser can make a request to a server where the key is added to the request out of site of html lurkers. Several users have used this method for years. Keys can also be disabled and created as needed in the Developer Network.

Okay, that makes sense,

Okay, that makes sense, except that I'm unable to find a decent node package for mapquest's APIs, which makes me think that creating a proxy server is not common.

If I just edit a URL sent by a client then now my server can be blamed for any malicious clients that try to attack the mapquest service.  So I really don't want to make a semi-transparent proxy that edits a URL with the credentials.  (aka just like SQL injection).

Nope, it's not very common.
Nope, it's not very common. Most users have their key in their JavaScript or backend code/config.

Limit to IP Address

One service I use for browser-based javascript calls limits the API Key for use only from designated IP Addresses. MapQuest might consider doing this as it would prevent keys from being stolen.

Limiting keys to specific
Limiting keys to specific referers is a function provided to Enterprise Edition customers. Limiting by IP is something we may offer in the future.

Love the smoke and mirrors security AKA lack of or lax security

I love how MapQuest treats security with smoke and mirrors. That was a sarcastic comment by the way.

Seriously, I searched the developer API docos, and could not find anywhere that mentioned how one should treat the Consumer Key. And here i found my answer, buried on a Forum Post. It is obvious MapQuest itself does not take security seriously, As admitted in a reply above, "most users have their key in their JavaScript"  Nice one, Mapquest. How do you prevent an "HTML lurker" to grab the key, use it on their app, then charge another account for it? 

Anyway, I will route all calls to MapQuest API's via server-side code, where the key can be hidden.


Hi, those are all valid

Hi, those are all valid questions. 


Users can revoke, delete, and create keys at any time. This can be done in the Manage Keys section.


Key usage can be monitored. In the Transaction History section, you can see overall and single key usage to determine if the number of transactions is expected.


Enterprise Edition customers can restrict requests to specific referers.


As you've mentioned, keys can be stored server-side for any API except interactive mapping SDKs which count transactions within the SDK and send those transaction counts back to the MapQuest servers.


The MapQuest APIs do not use any second-factor authentication. It was in the works but there was no demand for it so it was dropped.