2

In a Firebase project using Firebase Cloud Messaging (FCM), there is an auto-generated server key for cloud messaging. The FCM documentation does not indicate that there can be one and only one server using that auto-generated key (at least that I can find.) However the documentation does clearly state that server key should be securely stored.

First question: did I miss a single server documented restriction?

If there is no explicit restriction, it does occur to me that FCM might build in checks to ensure that requests for a given Firebase project to send messages do come from only a single IP address, rejecting requests from multiple IP addresses.

Second question: is a single server restriction implicit?

If it is the case that there can be multiple servers, each doing due diligence in protecting the privacy of the server key as well as anything else that is documented as "best (and safe) practices", it occurs to me that FCM might restrict requests based on the server type based on this statement:

The HTTP header must contain the following headers:

Authorization: key=YOUR_SERVER_KEY

Make sure this is the server key, whose value is available in the Cloud Messaging tab of the Firebase console Settings pane. Android, iOS, and browser keys are rejected by FCM.

Last question: what does the statement "Android, iOS, and browser keys are rejected by FCM." mean in the server type context? If this statement had said that requests from a mobile device (Android or iOS) or a browser would be rejected by FCM, that would be more clear. I am inviting an elaboration on this point but not a discussion.

pajato0
  • 3,628
  • 3
  • 31
  • 37

1 Answers1

3

  1. AFAIK, there is no single server restriction for FCM. There is also the topic of Receiving Messages from Multiple Senders, in which case, each sender (if a server), must have an access to your Server Key in order to send towards your Client App.

    So I'm fairly sure that there is no under the hood checking of the IP address (that restricts the sender from sending the message if it is different from the usual), unless you set it yourself (I'm not sure if it still available to set it via the API Console). It's also one of the reasons why the Server Key should be kept secret. In order to prevent unauthorized users from abusing it.

  2. I'm not sure what is the question here. Can you elaborate on "it occurs to me that FCM might restrict requests based on the server type".

  3. Before FCM, there used to be different type of API Keys, which are Server, Android, iOS, and Browser Keys. Developers were able to use their desired key regardless of the type for GCM, but then the restriction came to only allow Server Keys. See my answer here for more details.

    The options were also available before when creating a new API Key, but currently, when selecting to create an API Key, it will automatically generate and the option you'll be given is a restriction with one of the following:

    • None (Default)
    • HTTP referrers (web sites)
    • IP addresses (web servers, cron jobs, etc.)
    • Android apps
    • iOS apps
Community
  • 1
  • 1
AL.
  • 36,815
  • 10
  • 142
  • 281
  • 1
    Your link about multiple senders is something that I did miss that makes it very clear that multiple servers can share a single server key. However the documentation states that there is a limit of 100 multiple senders. Does this mean only 100 servers? Or would you interpret this to mean one could use thousands of servers but only 100 with unique sender id values? – pajato0 Mar 13 '17 at 08:09
  • 1
    From what you say, it seems clear that the Android, iOS and browser key comment applies to legacy use but is not relevant to new adopters of FCM. Correct? My question was trying to discern if the Google Cloud Messaging servers were filtering certain types of requesters. – pajato0 Mar 13 '17 at 08:17
  • A sender ID does represent to a Sender, so yes. Yup. The Android, iOS, Browser Keys were previous types of API keys, but it's no longer applied today. AFAIK, there isn't any checking done from where the request is coming from, since it is expected that so long as the request has the Server Key, it already *secure*. – AL. Mar 13 '17 at 08:19
  • Would you have a guess as to why the 100 unique sender limit? – pajato0 Mar 13 '17 at 08:26
  • If I were to guess, it's probably to prevent flooding of notifications to an app. Just imagine if all of those senders send a notification at the same time. That would be painful for the user. – AL. Mar 13 '17 at 08:28