Proposal: Pull API key from app.json / share with react-native-maps

[methodbox]

Using the API key as a prop presents obvious security issues. The key should be able to be pulled from app.json just as with react-native-maps.

I have a feeling this isn't something that is easy to do, but as it is currently it presents an issue that controls on the API key associated with things like the bundleIdentifier probably don't work as expected.

The best solution I can conceive is not making the prop required and using it from a dependency from react-native-maps, since this is required anyway.

I'm going to experiment with this on my own and I believe that as long as MapView (or another component which relies on an API key) is part of your component and wraps MapViewDirections it shouldn't be necessary to use the key directly.

Obviously, this means a bit of a rewrite on react-native-maps-directions to not request the key, but there must be some way to code around it.

[methodbox]

Thanks to an issue I opened at expo, I've discovered a way to solve this for Expo, at least. You use the Expo Constants.

Edit - Regarding expo I'm not 100% sure this solves the issue, though; this is essentially just importing the same string from a different source. I'm not sure there is a way to secure this beyond the API settings, but it does allow the importing of the bundleIdentifier, which can be used to secure the API key @google and currently does not work with either react-native-maps or RNMD. This would allow the fetch request to include the bundleIdentifier in it's request object and allow the API to be restricted to the app, solving the security concern.

_onPressTest = (): void => {
    const test = Constants.manifest.ios.config.googleMapsApiKey;
    console.log(test);
  };

So this would require native code to be configured to export the constants, but I'm gonna guess that react-native-maps is already doing this; there is probably a way we could just hook into that such that we import some kind of dependency of their's.

Here is how the RN docs explain it: https://facebook.github.io/react-native/docs/native-modules-ios#exporting-constants

Edit: Or we could just look @ how Expo is doing it; the expo-constants is a separate module; while I think having an Expo module be a dependency is a bad idea, borrowing some of what it does to pack into this module might be a good idea, assuming it can be maintained.

[methodbox]

I'm not sure how much more secure this would be, but it would certainly be more secure than no restriction, but this user on StackOverflow makes a good point:

https://stackoverflow.com/questions/52509599/how-does-googles-api-key-restrictions-work-for-mobile-apps?rq=1

As long as the bundleIdentifier is in the JSON header request, then it can be found.

The best solution is probably not requesting the API key at all and instead sending this request to your own external API on a server, securely and restricted, then making the request from there; only an authorized app could do this.

However, that still doesn't prevent a very determined hacker from just installing the app, then observing the request and attempting to sniff it, but that's a lot harder and more involved that reverse dumping an Android app, on the other hand it means it could be restricted @google by IP address which is a lot more secure.

[methodbox]

The best solution I've come up with so far is this.

I built a simple Express API to handle the "backend" API request; this would feasibly run from my cloud server and act as a proxy between Google and my app, allowing my to hide my API key and the app to be none the wiser. I haven't experimented with this adjustment to react-native-maps but I'll try that next; I'm sure it will work as it's so simple.

TS was driving me crazy, so this just JS for now, but it would be worth considering that TS would allow sanitizing the types that are returned for the API values before putting that burden on the app.

const express = require('express');
const fetch = require('node-fetch');
const queryString = require('querystring');
const app = express();
const apiKey = '***redacted Google API key';

app.get('/', (req, res) => {
  req.query.key = apiKey;
  const encodedQuery = queryString.stringify(req.query);
 
  fetch(`https://maps.googleapis.com/maps/api/directions/json?${encodedQuery}${apiKey}`)
    .then(res => res.json())
    .then(json => {
      return res.send(json);
    });
});

app.listen(5000);

And then in my module, to test locally, I just used "placeholder" for the API key, as I'm going to replace it when the request hits my API. My API then returns a JSON object identical to Google's response and we're golden.

    <MapViewDirections
        directionsServiceBaseUrl="http://192.168.1.133:5000/"
        region="US"
        origin={this.state.startMarker}
        destination={this.state.endMarker}
        apikey="placeholder"
        strokeWidth={5}
        strokeColor="blue"
    />

[methodbox]

For what it's worth, this solution also obscures the API key from server logs:

xx.xx.xx.xx - - [20/May/2019:02:59:28 +0000] "GET /api/?origin=37.78825,-122.4324&waypoints=&destination=37.7882987795,-122.42243453&key=placeholder&mode=driving&language=en&region=US HTTP/1.1" 200 2138 "-" "Expo/2.10.0.105122 CFNetwork/978.0.7 Darwin/18.5.0"

[bramus]

Thanks for your report and follow-up. I'm closing this issue, as:

• app.json is something specific to Expo, and not React Native in itself.
• The MapViewDirections component itself does not store the API key — It only gets it injected at runtime through a prop.

As a user of this component you can decide yourself where you want to store it. Be it in app.json, a config-file using react-native-config, an API call to your own API that you do upfront, etc. Securing those locations falls outside the scope of react-native-maps-directions.

[webraptor]

Decided to comment over here instead of opening a new issue.
The idea is that to properly secure the API keys, the API calls should be native, not from JS.
With the API calls triggered from JS, one cannot restrict API usage, so if the key is "stolen", doesn't matter how, it is compromised.

[chinalwb]

5 ys later, it is still a good one to comment.

That the best practice is to refactor this library to add an option to load Directions Data from developer's own backend.
say, introduce a new parameter for customized request for fetching the Directions data, then consume it as of how we do it now.

This would be a much safer way.

[chinalwb]

I had an update based on this awesome library.

https://github.com/chinalwb/react-native-maps-directions-via-server

It moved the apikey from app side to server side, by removing apikey from the library and marked directionsServiceBaseUrl as a required param.