Critical security update to the platform - May 2021

Dear Freshworks App Developers,

We hope this update finds you in health and safety.

We relish every moment of working along with app developers like you and conduct our practices in ways you will appreciate. Our team is simultaneously vigilant of security aspects that are of utmost priority to us as a platform and the users of your apps.

Our team has recently become aware of an issue that affects the security posture of our platform. As we take the necessary steps to address our security posture, this may require your attention for apps that are currently live in a customer’s instance. The specific risks we are trying to cover involve an agent gaining unauthorized access as an administrator within a Freshworks product.

As the very first step, until further notice, we have decided to temporarily suspend access to a few admin-specific API endpoints from the Request Method (regardless of app type) effective immediately.

Please find the list of API endpoints suspended temporarily.

To further elaborate the restriction, these API endpoints will only be restricted under the following conditions:

  1. The app uses the Request Method to make API calls to the endpoints outlined.
  2. The app uses an associated HTTP method for the affected endpoints, as captured in the list.
  3. API requests are made via the Request Method from the app frontend.
  4. API calls are made via the Request Method from the app backend with the static IP parameter set to true.

Based on our analysis, we expect very few apps are likely to rely on these endpoints. In case you find your app consuming any of these APIs via the Request Method, please get in touch with us at marketplace@freshworks.com. We will watch out for your requests to get you the necessary support as soon as possible.

In case your team identifies itself as a Freshworks developer partner, please also consider seeking assistance from Program Managers from Freshworks closest to your team.

You can read further on this topic through a Wiki article we recently added and comment to call out anything we may have missed addressing.

We would rarely want to take such drastic measures without notice, but unfortunately, our team felt this situation calls for it, in order to protect the interests of both you as a trusted developer and the customers that trust your work on our platform. We apologize for any inconvenience this may have caused and thank you for your support in making our platform more secure.

6 Likes

19 May 2021 :thread: Read Complete Annoucement

24 May 2021

Over the last few days, we have rolled out a couple of urgent updates to our platform to significantly enhance our security posture with respect to how installation parameters are used. First, we took steps to minimize the surface area of the impact. Next, we rolled out another update to how the Request Method on our platform can use secure installation parameters.

Our next planned update on this front is to start mandating that any domain that a Request Method makes a request to must be defined in the whitelisted-domains property of the app manifest. Our latest Freshworks CLI release v6.11.0 already enforces this.

Starting 4 June 2021, apps uploaded to the platform - either as a custom app or a public app - will be expected to whitelist any domain it wishes to make requests to via the Request Method. This change will currently not affect apps that were already deployed earlier than 4 June, and they will continue to work without a defined whitelist for now. We will share another update shortly for how your already deployed apps can comply with this requirement as well.

7 Likes

Hello @Saif,

Would it be possible to provide an example of what the iparams should look like moving forward? Maybe something basic like Freshworks product Domain and API key. The two most commonly used iparams for applications. And also a valid example of how to get requester or contact information based on using the request method and passing in the secure iparam in the headers property. Might be good to add as a wiki perhaps. Just a suggestion. :slight_smile:

Thanks,
Zach

3 Likes

Hi @Saif

Adding to @Zach’s question.

How would we know at compile-time what the value of Domain must be?
If we are expecting the customer to provide the Domain, we could not possibly include that in the manifest.json file under whitelisted-domains.

Shedding more light on this with an example would help.

Thanks,
Arun

1 Like

@arunrajkumar235, @Zach

you can use wildcard or template literal to specify the whitelisted-domains

eg:

"whitelisted-domains": [
    "https://*.freshdesk.com"
  ]

or

"whitelisted-domains": [
    "https://<%= iparam.domain %>.freshdesk.com"
  ]

the template literal is based on how you define the domain

Hope it helps

Thanks
Santhosh

5 Likes

Thanks for that update @Santhosh.

It would greatly help the developer community if wildcards and template literals were also documented in the official documentation.

3 Likes

The issue is, that when you want to test it locally it won’t accept it. Since it has to be https & not localhost domains.

How is it possible to test locally now?

1 Like

@JonathanHojtoft,

Very valid question. Thanks for asking.

I request you to use 3rd party services like ngrok which will help create a public URL out of localhost over https protocol. This way, Freshworks CLI will recognize the URL and make API calls.

Please feel free to create a new topic on the forum if you need further help.

2 Likes