This week we released a major update to the Infura Dashboard that gives developers the ability to specify additional information about their API requests in order to further secure the usage of their Infura APIs.

We will soon be enabling premium services and they will all require properly authenticated requests to utilize. With these premium services we will be introducing per user limitations to request traffic. This will allow us to continue to provide our service at the high reliability and availability that our users demand. To ensure that your project’s API traffic is accurately associated with your account, we are releasing these new features to help you secure your Project ID and Project Secret.

For each project ID in a developer’s dashboard, they can now control the following options:

  • Private Secret Required: Enabling this option will set this project to only serve requests where both the Project ID and Project Secret are included in the request. We have updated our documentation to outline how to properly send your requests with a Project Secret. We will be releasing more information shortly about the importance of Project Secrets and how they should be used with requests.
  • AllowList Contract Addresses: You can add specific Ethereum addresses that your application uses, either smart contracts or wallets. For methods that explicitly refer to address parameters, this will restrict requests using those methods to only allow requests referencing addresses identified in your AllowList.
  • AllowList User Agents: User Agent is commonly utilized in the request header by browsers and mobile apps to identify the software or app making the requests. Configuring entries here will only allow requests to the AllowListed user agents. We do case sensitive partial matching to check these entries.
  • AllowList Origins: Modern browsers sending HTTP requests will generate the Origin header on all POST requests as the URL of the page that created the request with path information removed. Setting the origin on your project ID will only allow requests to the AllowListed entries. We support wildcards as part of the prefix when checking these entries, e.g. *

Here are some high level functionality notes important to keep in mind when configuring these AllowLists:

  • If no entries are added to any of the AllowLists, all requests will be served using that project ID. Otherwise, if entries are added to any of the AllowLists, only requests containing the AllowListed entries will be served.
  • If you apply multiple AllowList entries to a single project ID, entries of the same type are boolean ORed together and each AllowList type is then boolean ANDed with the others.

For example, if you have the following AllowList entries applied to your project ID;

  • Addresses:0x1234, 0xBEEF
  • User

Then the effective filter logic would be,

  • IF( Address=("0x1234" OR "0xBEEF") AND UserAgent.contains("") THEN ALLOW

Please see the docs for even more information on how to use these new options, Infura Documentation.

As part of our transition to dashboard generated project IDs for sending API requests we wanted to include industry best practices for managing API requests. You can start taking advantage of these new security features now.

For the latest timing on the transition, please see the following post, Dashboard Transition Update

As always, we are here to help with any new features and your transition to dashboard generated project IDs. If you have any questions please reach out to us at our Community page or by email at [email protected].