All apps that are to be published in Freshworks Marketplace go through a code review where they are vetted for code quality, correctness, and security. Here are a broad set of guidelines to be followed while developing apps.
The following security-related guidelines are mandatory. We recommend that you follow them even for custom apps.
- Use secure iparams for sensitive information: Non-secure iparams should not be used to obtain sensitive information, such as API keys, usernames, passwords, during app installation as agents will be able to inspect these values in the browser and access them.
- Do not log sensitive information: Sensitive information (especially privileged customer/user information) should not be stored in console logs as they are easily accessible.
- External services must be protected: If an app requires working with an external custom web service (e.g., Heroku), the web service must require authentication for any access so that privileged information is secure and only accessible through the app.
- Use the Request API for API calls: Wherever requests to external services are to be made from the front end of an app, the Request API must be used. Direct Ajax calls must be eschewed under all circumstances so that the app is compliant with popular security standards.
- Pack all Freshworks SDK interactions within the app package: All source code that interacts with the Freshworks SDK (for references, see client) must be packed within the app package submitted for review so app users can tell what data from their accounts is used by the apps. Business logic that uses this data can remain outside of the app package, if required. If a large part of the app source code is hosted outside the app, reviewers are likely to seek further information on the overall app architecture and how the business logic makes use of any personal information sourced by the app from a user’s account.
Test your app : You can test your app by running the following command in your terminal.
$ fdk run
The main components of the coverage summary that we deal with are:
- Statement coverage: Checks if each statement in the code has been executed at least once.
- Branch coverage: Checks if each branch of each control structure has been executed. For example, in an IF statement, both the true and false branches need to be tested.
- Function coverage: Checks if each function (or subroutine) has been called in the code.
- Line coverage: Checks if each line of code has been executed (excluding comments/ conditionals).
- Handle failures: All failure cases must be handled in both the front end and back end of your apps. A proper error response must be returned from the serverless component of the app to the front end. This ensures business continuity for users in the face of unexpected errors and avoids negative experiences.
- Clean up: If any setup actions were performed during the app install (e.g., registering an external webhook), the same must be undone and cleaned up during app uninstall.
- Use reliable external services: Any external web services used must be capable of supporting considerable load and must have reliable uptime.
- Readable and maintainable code: All submitted code must be readable and maintainable to ensure faster code review feedback and certification.
- Do not minify code: Any code submitted with an app (with libraries included as assets) must be provided in an unminified/untranspiled form so that code reviews and app certification processes are faster.