Requests your Server can Trust

We often receive questions about developers wanting to build an app that must securely fetch data from servers they host. These servers are typically hosted behind a firewall, readily accessible to clients on the same network as the server. Today’s post will walk you through various options to build a secure app that works with these servers.

Making your server accessible

A representation of your app sending a request to your server from within a Freshworks product.

By virtue of being a subscription-based platform, the Freshworks platform only supports connecting your app with services that are accessible over the Internet. Here is an overview of opening your server securely to the Internet.

1. Set up your NAT gateway to forward requests to your server from the internet.
2. Configure firewall rules to allow only HTTPS traffic from the Internet to one single port associated with your server.
3. Set up a domain for your service with an SSL certificate from a reputed provider.
4. Configure DNS routing for your service domain.

This video tutorial will give you an overview of what is required.

Finally, you must add an authentication layer in front of your server to reject requests that cannot be authenticated.

Note: It is beyond the scope of this post to go into specific details of how this is achieved in particular scenarios.

Building an app that can be trusted

While your app sends requests to the server over HTTPS, it also presents some form of authentication with each request so the server can trust these incoming requests. You can choose to secure your requests with the following options.

1. Shared Secret (Complexity — Low, Security — Moderate)

A unique secret, known only to your server and app, is embedded in a request header for each request sent to your server.

2. JWT (Complexity — Medium, Security — Strong)

A token is generated using the secret and embedded with the request. The token has a short shelf-life and becomes invalid within a few seconds of creation.

The secret can be introduced to your app in two different ways.

1. server.js: Define the secret as a constant in your app’s server.js and send requests to your server only from this serverless app.
2. iparams.json (recommended): Define the secret as a secure installation parameter for your app, and key it in when you install or update the app.

The shared secret defined as an installation parameter.

The following code snippet demonstrates how you could use the shared secret in a GET request made to your server.

Code snippet demonstrating the use of a shared secret.

You can also take this further by following our guide to use JWT authentication between your app and your server.

Besides being more secure, the iparams.json method allows you to change the secret without redeploying the app.

Note: We do not recommend storing and using shared secrets directly in your front-end app because this will expose it to any agent who has access to your Freshworks account.

What about IP whitelisting as a security measure?

We do not recommend IP whitelisting as an adequate security measure because it suffers from the following exploits -

1. Anyone could write a custom app, run it in our infrastructure masquerading as your own app, and gain access to your server(s).
2. Well-known brute force measures are available to spoof IP addresses over TCP connections.

At Freshworks, we realize that integrations with your individual silos of data are critical to the success of your adoption of any SaaS product. Do reach out and let us know how you would like us to make this even more seamless for you.