Some Meteor applications are released solely as mobile applications. They’re intended to be experienced natively as a Cordova-powered application, rather than on the web through a browser.

From a security perspective, does this matter? Are security assessments for mobile-only applications approached differently than web-only, or web and mobile applications?

The answer to both questions is a resounding no!

Web is Always an Option

An interesting side-effect of the Meteor build process means that the “web” version of an application is always accessible, even if you intended to release it exclusively as a native mobile application.

During the mobile build process, you point your application at a hosted Meteor server. The mobile application communicates with the server, pulling down data and updated application code.

> meteor help build
...
Options:
  --server  Location where mobile builds connect to the Meteor server.
            Defaults to localhost:3000. Can include a URL scheme
            (for example, --server=https://example.com:443).

As expected, the application can also be accessed by navigating to this server URL directly with a browser.

This browser build can’t be disabled with current versions of Meteor. Trying to remove the “browser” platform results in an error:

> meteor remove-platform browser

While removing platforms:
error: browser: cannot remove platform in this version of Meteor

This means that the front-end of a Meteor application can always be seen by prying eyes.

Unzipping The Application

Let’s imagine that we’re trying to assess a Meteor mobile application called FooApp.

When we only have access to the compiled mobile application, how can we discover the Meteor server’s URL?

It turns out this is a fairly straight-forward process. We’ll dig into it for iOS applications (*.ipa archive files), but the same process applies to Android applications (*.apk archive packages).

Once we’ve downloaded FooApp through iTunes, its *.ipa file can usually be found at ~/Music/iTunes/iTunes Media/Mobile Applications/FooApp<version>.ipa.

Interestingly, iOS application archives can be unzipped using a standard archiving tool. The first step to discovering our server URL is to unzip the archive:

unzip FooApp<version>.ipa -d FooApp

We can now peruse through the contents of the FooApp bundle in the FooApp folder.

Finding the Server

Once we’ve unzipped our application, the server URL is within our reach.

To discover the server URL, open FooApp/Payload/FooApp.app/www/application/index.html. In that file, you’ll find a URL-encoded __meteor_runtime_config__ variable.

You can copy and paste that __meteor_runtime_config__ declaration into a browser console, and then print it in a more human friendly format:

__meteor_runtime_config__ = JSON.parse(decodeURIComponent("..."));
JSON.stringify(__meteor_runtime_config__, null, 2);

The result should look something like this:

{
  "meteorRelease": "METEOR@1.3.3-ddp-batching-beta.0",
  "ROOT_URL": "https://www.fooapp.com/",
  "ROOT_URL_PATH_PREFIX": "",
  "DDP_DEFAULT_CONNECTION_URL": "https://www.fooapp.com/",
  "autoupdateVersionCordova": "86e83cfe388118db86733f1333e3a2962fcad1b6",
  "appId": "ABCDEFGHIJ1234567890",
  "meteorEnv": {
    "NODE_ENV": "production"
  }
}

You’ll notice that both ROOT_URL and DDP_DEFAULT_CONNECTION_URL point to "https://www.fooapp.com/". This is the server URL that we’ve been searching for!

Navigating to the server would deliver all of the client-side code to our browser (even if it’s guarded by a Meteor.isCordova check), and give us access to call all Meteor methods and publications.

Now we can assess our mobile Meteor application just like any other Meteor application!